Repository navigation
perf: array element store pays a cross-crate guard call per element (15% of bench_array_ops) #7396
Description
bench_array_ops is 4.5× slower than Node (262 vs 58 by the benchmark's own timer), and more than half the time is outside the generated code.
Measured
sample over a --debug-symbols build:
| samples | frame |
|---|---|
| 326 | perry_fn_…__runArrayBenchmark (generated) |
| 103 | js_typed_feedback_numeric_array_index_set_guard |
| 89 | js_array_fill_f64_iota_extend |
| 87 | js_array_grow |
| 52 | js_gc_temp_root_{push,get,truncate} |
The workload is pure integer array traffic — arr[i] = i, sum += arr[i], a swap loop, arr[i] % 2.
What the guard actually is
Not overhead for a disabled feature — I assumed that first and it is wrong. With typed feedback off (the default) js_typed_feedback_numeric_array_index_set_guard does the real work:
if !typed_feedback_enabled() {
return (index >= 0
&& is_numeric_value_bits(value.to_bits())
&& numeric_array_index_set_guard(arr, index, require_in_bounds)) as i32;
}It is the check that authorises the fast store. The problem is where it lives: a 5-argument cross-crate call per element, for a predicate whose common case is
index >= 0— statically known for ani32loop counter- value is numeric — often statically known
- plain array + in bounds — one length load and compare
(*header)._reserved & GC_ARRAY_RAW_F64_LAYOUT— one flag-bit test on the GC header
Every one of those is a handful of inline instructions. This is the "native-able primitive became a runtime call" pattern the earlier audits named, in its clearest form.
Suggested direction
Emit the fast-path predicate inline in codegen and keep the helper as the slow-path fallback, so a store that stays on the raw-f64 layout never leaves the generated function. The layout flag test is the load-bearing part and is a single masked load.
js_array_grow (87) and js_array_fill_f64_iota_extend (89) are the growth path for arr[i] = i on an initially-empty array and are worth a separate look — Node pre-sizes far more aggressively.
Caveat on the measurement
Taken on a machine at load ~5.9, using minimum-of-N and the benchmark's own internal timer rather than wall clock. The sample proportions are stable across runs but the absolute ratio should be re-confirmed on a quiet host before it anchors any target.
Activity
docs(plan): fold in the 2026-08-04 findings (#7397)
proggeramlug commentedon Aug 4, 2026
Negative result on the growth path — measured properly, do not retry.
js_array_growHOLE-initialises new slack with aptr::writeloop, and I proposed converting it to aslice::fillon the theory that the loop emitted one scalar store per slot. That theory came from a vacuous check: I ranotool | awk '/_js_array_grow:/…'against a stripped binary, the symbol was absent,grep -creturned 0 both before and after, and I read "0 paired stores" as evidence.Redone with a check that can fail — resolve the address via
nm, extract from there:LLVM already vectorises that loop. The paired stores are there in the baseline. The
slice::fillrewrite is therefore a no-op, which is exactly what the timings said (min 238 vs 244 across 8 runs — inside the noise band even before load became a problem).So of #7396's 176 samples across
js_array_grow+js_array_fill_f64_iota_extend, the hole-init is not the addressable part. If there is a win in the growth path it is in the policy — Node pre-sizes far more aggressively forarr[i] = ion an empty array, so the number of grow-and-copy cycles is the lever, not the cost of each one.The store-guard half of this issue (103 samples,
js_typed_feedback_numeric_array_index_set_guard) is untouched by this and remains the real target.Method note worth carrying: a disassembly check that greps a symbol name only works on a
--debug-symbolsbuild, andgrep -creturning 0 is indistinguishable from "pattern never matched". Resolve the address withnmfirst and assert the extraction is non-empty.docs(plan): record the resolved speed picture (#7405)
perf(codegen): inline the numeric array store guard for element-to-el…
proggeramlug commentedon Aug 5, 2026
Re-measured on the release profile before implementing the suggested direction. The direction should change: the guard is not in the release profile at all.
The original profile was taken on a non-shipping configuration
js_typed_feedback_numeric_array_index_set_guardis a cross-crate call. Theperry-devprofile is opt-level 1 with no LTO, so it cannot be inlined there and shows up as the #1 runtime cost (103 samples). The shipping profile uses thin LTO, which inlines it: grepping the release profile for the symbol returns 0 frames. Emitting the predicate inline in codegen would therefore have optimised a cost that does not exist in shipped binaries.Release profile (2500 timed iterations,
--debug-symbols, 13,530 samples)perry_fn_…__runArrayBenchmark(generated)_tlv_get_addrjs_gc_temp_root_pushjs_array_fill_f64_iota_extendjs_gc_temp_root_getjs_gc_temp_root_truncatejs_array_growTemp-root machinery 11.3% +
_tlv_get_addr12.2% = 23.5% — as much as the generated code itself, and the_tlv_get_addrcallers are dominated by those samejs_gc_temp_root_*entries. This is macOS dynamic TLS resolution: everythread_local!access in the runtime goes through the resolver rather than a direct offset.So the lever on this benchmark is Layer 3 runtime rooting and its thread-local access cost, not the array guard.
The gap is also half what this issue records
Min-of-9, arms interleaved to cancel drift, host load ~5.5: perry 123 / node 53 = 2.32×, not 4.5×. The dev-runtime arm gives 2.25×, so the ratio is essentially profile-independent — what changes between profiles is where the time goes, not how much. The 262 figure predates recent work.
It is not the Layer 2 backend
A/B'd the root backends on the same binary: shadow stack (
PERRY_RS4GC=0) 121 vs statepoints 123 — within noise. Statepoints address generated-code liveness; these temp roots are runtime-side (Layer 3), so the backend choice does not touch them. Worth stating because "reduce root density" could otherwise be mistaken for a Layer 2 task here.Suggested redirect
_tlv_get_addris the single largest non-generated term, and it is a representation choice, not an algorithmic one.js_array_grow+js_array_fill_f64_iota_extendtogether are only 4.1% in release, so the growth-path follow-up is also smaller than the dev profile implied.Caveats: host load ~5.5 (not a quiet box);
sampleattribution is statistical, and the_tlv_get_addr→ temp-root attribution is from caller context rather than exact accounting.proggeramlug commentedon Aug 5, 2026
Correcting my previous comment — its central claim is wrong. The original direction stands.
I claimed the guard was absent from the release profile and had been inlined by thin LTO. That came from a broken profile parse, and two direct checks refute it:
nmon bothlibperry_runtime.aand the linked--debug-symbolsbenchmark binary showsjs_typed_feedback_numeric_array_index_set_guardpresent. It is a real call, not inlined away.runArrayBenchmarkcontains 6 guard call sites in the hot loops — 2numeric_array_index_set_guardand 4numeric_array_index_get_guard, alongside 4js_array_index_get_fallback_boxedand 4js_array_numeric_value_to_raw_f64.So the guard is called per element exactly as this issue describes, and inlining the fast-path predicate in codegen is still the right direction.
Also retracting the percentage table.
sample's call graph reports inclusive counts per tree node; I summed them across all nodes, which double-counts every frame along each stack — that is whystartandmaineach appeared at ~16% next to their own callee. The "temp roots 11.3% +_tlv_get_addr12.2% = 23.5%" figure is not supported. Two later attempts to re-derive self time from the same file produced obviously impossible results (startas a leaf holding 98%), so I have no reliable profile breakdown to offer and am not replacing the table with another guess.What survives, because it is direct timing rather than sampling:
PERRY_RS4GC=0(shadow stack) vs statepoints, same binaryTwo things follow that are worth keeping:
My apologies for the noise — I posted an analysis that would have redirected this issue away from a valid fix.
proggeramlug commentedon Aug 5, 2026
This is already fixed on
main— by #7421, merged today — and the issue was never closed. Posting the evidence so the next person does not reimplement it as I just did.crates/perry-codegen/src/expr/index.rscarries aninline_write_tierwhose comment names this issue directly: the tier previously required the RHS to be canonical-raw-f64 by construction (expr_produces_canonical_raw_f64), which gated it off for element-to-element traffic (arr[i] = arr[j]) — the reverse-in-place loop this issue profiled. #7421 replaced that static flag with a runtime test of the same predicate, so the tier now covers those stores.That also explains the discrepancy I reported earlier: I measured 2.32× against this issue's recorded 4.5×. The gap did not close through unrelated drift — #7421 closed the specific term this issue identified.
What is genuinely left
The remaining
js_typed_feedback_numeric_array_index_set_guardcalls inbench_array_ops' IR are all on the extend path — they passrequire_in_bounds = 0and sit inidxset.check_cap/idxset.extend_inline. There are zeroidxset.bounded_numericblocks in the module, i.e. the in-bounds diamond this issue's suggested fix targeted is not even reached by this benchmark.So the append case (
arr[i] = igrowing an initially-empty array — the benchmark's first loop) still pays a five-argument cross-crate call per element. That is the residue, and it is a different problem from the one in the issue body: it has to reason about capacity, sealing and the extend policy, which the in-bounds tier gets to ignore.Suggest either closing this as fixed by #7421 and opening a narrow issue for the extend path, or retitling it to the extend path explicitly. Leaving it open with the original body is what cost me this round.
Correcting my own record here
My first comment claimed the guard was absent from the release profile and inlined by LTO. That was wrong and I retracted it;
nmshows the symbol present and the IR has real call sites. The percentage table in it came from summingsample's inclusive call-graph counts, which double-counts every frame along a stack — ignore that table entirely. The only numbers in this thread I would still stand behind are the direct timings: 123 vs 53 release, 128 vs 57 dev, and shadow-stack 121 vs statepoints 123.proggeramlug commentedon Aug 5, 2026
Measured confirmation that this is complete, including the extend case — and a retraction of the "residue" I claimed above.
I said the append path still pays a per-element guard call because the remaining IR call sites carry
require_in_bounds = 0. That was reading static call sites as if they were dynamic cost, which is the same mistake twice in this thread. Those sites are the tier's cold arm;inline_write_tier'sguard_oknever requires in-bounds — it checksindex_nonnegative,length_sane,capacity_saneandlength_within_capacity, then branches toguarded, withcheck_cap/extend_inlinedownstream. Extend is inside the tier, not outside it.The A/B
No rebuild and no env knob (
PERRY_TYPED_FEEDBACK=1would also switch on observation, confounding the result). Instead, one source line that trips the sticky latch the tier reads:Same binary, same host, 7 runs each, min reported:
bench_array_opsTOTAL13.8×. The tier is carrying essentially the entire benchmark; the out-of-line guard is not on the steady-state path at all.
Caveat stated plainly: prototype pollution also changes hole/OOB semantics, so some of that 1731 is other slow paths rather than the guard call alone. It bounds the tier's value from below, it does not attribute all 13.8× to one call.
Conclusion
#7421 closed this issue's mechanism completely — in-bounds and extend. The 4.5× in the body is stale; the current gap is 2.32× (release, min-of-9, interleaved), and it is not in the array store guard, nor in the root backend (shadow stack 121 vs statepoints 123).
Recommend closing as fixed by #7421. I would not open a follow-up for the extend path — the measurement above says there is nothing there. Where the remaining 2.32× lives is genuinely unknown; I could not get a trustworthy profile (see the retraction above), and I would rather leave that unanswered than post a third guess.
docs(engine-plan): step 7 is a measured backlog; sequence the JSON wo…
proggeramlug commentedon Aug 6, 2026
Closing as fixed by #7421 (merged 2026-08-05), per the evidence in the two comments above:
expr/index.rscovers exactly the element-to-element stores this issue profiled (its comment cites this issue number), including the extend path — the remaining IR guard calls are the cold arm.The remaining gaps live in the measured backlog in
docs/engine-plan.mdstep 7 (json/map/batch rows) rather than here.docs(engine-plan): 2026-08-06 ticket sync and repsel stack position (#…
arrays: the element store guards on one header word (S2) (#11660)