perf: arr[i] = v on an untyped plain Array is 52× slower than Node (no inline store: one js_dyn_index_set_strict call per element; the same loop with a number[] annotation is 1.7×) #10513

Found by the package performance audit (real npm packages compiled from source, profiled against Node 26.5.1) and
re-measured on Perry 7661bc0 (v0.5.1589), Linux x64. An index store into a plain Array whose receiver is not
declared as an array (every receiver in plain .js, and any any) is never inlined. Each element write calls
js_dyn_index_set_strict, which re-classifies the receiver through a stack of registry, prototype and arguments checks.
A fill/sum loop is 52× slower than Node. The identical loop with the parameter annotated number[] is 1.7×.

Reproduction

bench.ts (27 lines):

const variant = process.argv[2] || "any"; const N = Number(process.argv[3] || "400000");
// node-forge jsbn: BigInteger digits live in a plain Array, written/read by index through an untyped receiver
function fill(d: any, n: number): void { for (let j = 0; j < n; j++) d[j] = (j * 7) & 0xfffff; }
function sum(d: any, n: number): number { let s = 0; for (let j = 0; j < n; j++) s += d[j]; return s; }
function fillT(d: number[], n: number): void { for (let j = 0; j < n; j++) d[j] = (j * 7) & 0xfffff; } // CONTROL: same body,
function sumT(d: number[], n: number): number { let s = 0; for (let j = 0; j < n; j++) s += d[j]; return s; } // declared number[]
let d: any = variant === "grown" || variant === "grown_gc" ? [] : new Array(80).fill(0); // "grown": grown by d[j] = v
fill(d, 80);
if (variant === "grown_gc" && typeof (globalThis as any).gc === "function") (globalThis as any).gc();
function BigInteger(this: any) { this.data = []; } // jsbn am1 verbatim (Montgomery multiply-add inner loop)
function am1(this: any, i: number, x: number, w: any, j: number, c: number, n: number): number {
  while (--n >= 0) { const v = x * this.data[i++] + w.data[j] + c; c = Math.floor(v / 0x4000000); w.data[j++] = v & 0x3ffffff; }
  return c;
}
BigInteger.prototype.am = am1;
const a = new (BigInteger as any)(), w = new (BigInteger as any)();
for (let k = 0; k < 80; k++) { a.data[k] = (k * 2654435761) % 0x4000000; w.data[k] = (k * 40503) % 0x4000000; }
function run(n: number): number {
  let acc = 0;
  for (let r = 0; r < n; r++) {
    if (variant === "am1") acc = (acc + a.am(0, (0x3456789 + r * 7) % 0x4000000, w, r % 3, 0, 76)) % 1000000007;
    else if (variant === "typed") { fillT(d, 76); acc = (acc + sumT(d, 76)) % 1000000007; }
    else { fill(d, 76); acc = (acc + sum(d, 76)) % 1000000007; }
  }
  return acc;
}
run(N / 5 | 0); const t0 = performance.now(); const cs = run(N); console.log(`${variant} checksum=${cs} ms=${(performance.now() - t0).toFixed(1)}`);

PERRY_NO_AUTO_OPTIMIZE=1 perry compile bench.ts -o bench
for v in any typed am1; do node bench.ts $v 400000; ./bench $v 400000; done

Measurements

Medians of 3 runs on a shared, loaded host. Instruction counts are the load-independent figure (whole-process
instructions:u, which includes the N/5 warm-up). N = 400,000. Each fill/sum iteration does 76 writes and 76 reads.
Each am1 call does 76 inner iterations.

Checksums are identical in all variants. The any variant uses 22× the instructions of the typed variant, and the
only source difference is the parameter annotation.

perf record of the any variant (reads on this presized array are inline; there is no js_array_get_f64 in the
profile):

The typed control spends 82 % in the compiled loops and 6 % in js_typed_feedback_packed_f64_range_loop_guard.

Impact

• node-forge 1.4.0 RSA-2048 sign / keygen (98× / 80× Node; numeric-group audit profile, v0.5.1587):
  • The "array ops" bucket is 29.0 % / 30.6 % of Perry time.
  • Buffer-registry checks called from the array get/set path add another 10.3 % (sign).
  • jsbn's am1 (lib/jsbn.js:81-88) is 64.8 % / 76.5 % inclusive. It stores w.data[j++] = v&0x3ffffff.
  • One signature is 276k am() calls and 6.29 M inner iterations. Perry takes ~178 ns per iteration; Node takes
    ≤2.8 ns.
• @noble/hashes blake3: about 3 %.
• Other affected code: every jsbn-derived bignum library and every plain-JS algorithm that keeps numbers in a
  []-built array (matrices, DP tables, pools).

Mechanism

• Only typed-array kinds get inline arms (verified). The generic obj[i] = v lowering in
  crates/perry-codegen/src/expr/index_set_typed_array.rs emits inline stores for the typed-array kinds only. The
  slow arm calls js_dyn_index_set_strict for every other receiver, including a live plain Array (lines 280-295).
• Each store re-classifies the receiver (verified by source and profile). The call path is
  js_dyn_index_set_strict (crates/perry-runtime/src/value/dyn_index.rs:550) →
  js_array_set_index_or_string_with_strictness (crates/perry-runtime/src/array/indexing_keyed.rs:361) →
  js_array_set_f64_extend_strict_impl (crates/perry-runtime/src/array/indexing.rs:1184-1250). Along the way, every
  store runs:
  • three dense-store lanes;
  • clean_arr_ptr_mut, is_registered_buffer and lookup_typed_array_kind;
  • the Array/Object prototype index latches and resolved flags;
  • js_string_addref_if_heap_string;
  • the dispatcher's temporal-cell, arguments-object and prototype-address checks.
• The inline tier exists but needs a declared type (profile verified; the admission rule is inferred). With
  d: number[] the same loops run in compiled code behind js_typed_feedback_packed_f64_range_loop_guard, a
  runtime-checked loop guard. So a guarded inline packed-f64 store tier exists, but only declared-array receivers are
  admitted to it.

What fast looks like

• Option A: admit untyped receivers to the same guarded packed-f64 loop/store tier. The guard re-validates the
  receiver at runtime, so no declared type has to be trusted.
• Option B: emit a per-site guarded inline store with the existing call as the cold arm. The guard checks: GC type
  == ARRAY, not forwarded, no descriptor flag, index < length, and the value is a plain double.
• Targets:
  • any within 2× of typed (≤ ~35 instructions per element op) and ≤2× Node.
  • am1 ≤3× Node, once perf: bitwise operators on destructured, number-annotated or untyped values are 56× slower than Node (a js_dynamic_bit* call per operator, ToInt32 via software fmod) #10511 (the &) and perf: reads of an Array grown by a[i] = v or push are 54× slower than Node (binding keeps the forwarded old head; every inline read bails out) #10514 (reads of grown arrays) are fixed too.

Notes

• perf: reads of an Array grown by a[i] = v or push are 54× slower than Node (binding keeps the forwarded old head; every inline read bails out) #10514 is the read-side cliff that am1 also hits: its arrays are grown by index, so reads bail out of the
  inline path.
• Boolean array stores have no inline fast path: 20x node, ~82% of the time in per-store bookkeeping calls #9237 (closed) added an inline path for boolean array stores. perf(codegen): loop-version stable packed Array and Array-subclass iteration #8690 and perf(codegen): version nested packed loops over immutable closure captures #8773 (closed) loop-version stable packed
  arrays for proven receivers. Open PR perf(runtime): stop re-deriving the receiver on every array push (−74%) #10414 speeds up push, not index stores.