perf: array element store pays a cross-crate guard call per element (15% of bench_array_ops)

[proggeramlug]

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 an i32 loop 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.

[proggeramlug]

Negative result on the growth path — measured properly, do not retry.

js_array_grow HOLE-initialises new slack with a ptr::write loop, and I proposed converting it to a slice::fill on the theory that the loop emitted one scalar store per slot. That theory came from a vacuous check: I ran otool | awk '/_js_array_grow:/…' against a stripped binary, the symbol was absent, grep -c returned 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:

extracted 201 lines
  6 stp
  1 str

LLVM already vectorises that loop. The paired stores are there in the baseline. The slice::fill rewrite 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 for arr[i] = i on 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-symbols build, and grep -c returning 0 is indistinguishable from "pattern never matched". Resolve the address with nm first and assert the extraction is non-empty.