repsel: array-callback parameters carry no element-shape fact — 10.1% vs the equivalent for-loop (#7151 item 2) #8103

Activity

1. proggeramlug commented on Aug 15, 2026

   

   proggeramlug

   on Aug 15, 2026

   ContributorAuthor

   More actions

   Verdict: still real, but the published **10.1% is wrong by more than an

   order of magnitude**, and the prize is a minority of the gap. Keeping open,
   re-scoped. I did not fix it.

   Re-measured at fb87d8923, macOS arm64, --profile perry-dev compiler and
   libperry_{runtime,stdlib}.a, PERRY_RUNTIME_DIR pinned,
   PERRY_NO_AUTO_OPTIMIZE=1, /usr/bin/time -l, medians of 3 interleaved.

   The programs from this issue, reproduced exactly

   Module-level, 20,000 elements, 200 reps, both printing the issue's own
   t: 80000000000:

   	Ptr<Shape>	instructions	peak RSS	vs baseline
   for + const r = A[i]	2 selected	92,113,198	4,587,928	—
   A.forEach(cb)	0 / 1 denied	1,320,317,570	4,587,928	+1333%

   The Ptr<Shape> verdicts match this issue exactly (2 vs 0/1 denied), and the
   printed checksum is byte-identical to the one quoted here, so it is the same
   workload. But the absolute numbers are not: this issue reports
   15,800,121,583 for the for baseline; current main runs the same
   program in 92,113,198 — 171x less. Perry finishes it in 10 ms wall; Node
   26.5.1 takes 140 ms.

   The physics still agree: the increment attributable to forEach was
   17,391,614,644 - 15,800,121,583 = 1.59 G there, and it is 1.23 G here.
   So both measurements found roughly the same absolute cost; the "+10.1%" is
   that cost divided by a 15.7 G common term that current main does not
   reproduce and that I could not reconstruct. Whatever it was, it diluted the
   ratio ~170x. The percentage in the title should not be used to schedule
   this.

   Function-local formulation (same class, same reads, arr built and read
   inside one function), which is where the versioned element-shape clone
   actually fires:

   	instructions	peak RSS
   for + const x = arr[i]	91,147,942	4,637,080
   arr.forEach(cb)	1,907,932,078	4,899,224

   21x, ~14 instructions per element read vs ~469. Linear in reps
   (100/200/400 checked), so nothing is being optimised away.

   Sizing the actual prize — the part that matters

   The element-shape fact only addresses the field reads. Isolate them by
   replacing the callback body with s = s + 1 (same 4M invocations, no field
   traffic):

   	instructions
   forEach, s = s + x.a + x.b	1,907,932,078
   forEach, s = s + 1	1,472,051,254
   difference (8M guarded field reads)	435,880,824

   So ~54 instructions per guarded field read, and ~23% of the forEach
   program's total cost. The other 77% is per-callback machinery that an
   element-shape fact does not touch — ~368 instructions per invocation.

   The callback body IR says the same thing:

   2 js_typed_feedback_class_field_get_guard    <- what #8103 would delete
   2 js_object_get_field_by_name_f64            <- what #8103 would delete
   2 js_dynamic_string_or_number_add            <- capture-box accumulator
   2 js_closure_get_capture_bits                <- capture-box accumulator
   1 js_box_get_bits / 1 js_box_set_bits / 3 write barriers
   

   Re-scope

   1. The item is real. The fact is genuinely absent (Ptr<Shape> 0 selected / 1 denied) and it costs ~54 instructions per field read.
   2. Its ceiling is ~21% of the forEach form, not 10.1% and not 21x.
      Landing clone-and-route on the callback parameter would take the probe from
      1.91 G to roughly 1.51 G — still 16x the equivalent for loop.
   3. The dominant term is a different issue that does not exist yet: array
      higher-order callback invocation costs ~368 instructions per element
      (closure dispatch through js_array_forEach + capture-box traffic for any
      accumulator the callback closes over). That is where the 21x lives, and it
      subsumes both shapes (1) and (2) named in this issue, including the
      reduce accumulator case that motivated the batch.ts reference.

   Concretely: I would file the invocation-cost issue first, measure a
   forEach/map/reduce inlining or a raw-f64 capture-box tier against it, and
   only then decide whether the remaining ~23% is worth the clone-and-route
   obligation. On the campaign's own record — repsel's realised effect on root
   count was ~4% with one arm negative — a 23%-ceiling item behind a 77% one is
   not the next thing to build.

   Not measured / caveats

   • --profile dist and --release runtime. The 23/77 split is measured with an
     opt-level-1 runtime; both sides of that split are runtime calls
     (js_object_get_field_by_name_f64 and js_typed_feedback_class_field_get_guard
     on one side, js_array_forEach and js_closure_get_capture_bits on the
     other), so the ratio is less biased than a generated-vs-runtime comparison
     would be — but it is not zero-biased, and I did not bound it.
   • map / reduce measured separately from forEach.
   • x86-64.
   • No implementation attempted, so there is still no cost estimate for the
     clone-and-route side.
2. proggeramlug

   closed this as completedin #8281on Aug 17, 2026