moonbitlang / core / 6230

91%

push

github

perf(builtin): count rev_foldi's index up instead of deriving it per iteration

Completes PR #3784 (mizchi) on current main, where three of its four
FixedArray reverse-iteration optimizations have already landed. The
remaining delta is rev_foldi, which computed the ascending index as
len - i - 1 on every iteration inside the descending range loop.

Instead of that PR's C-style three-variable loop, the index becomes a
second loop state of the same readable range form:

  for i in self.length()>..0; index = 0, acc = init {
    continue index + 1, f(index, acc, self.unsafe_get(i))
  }

Measured identical to the C-style loop (11.19 vs 11.20 us native) and
faster than main on all three backends (rev_foldi, n=100K, sum fold):
native 14.88 -> 11.19us (1.33x), js 72.4 -> 59.9us (1.21x), wasm-gc
75.5 -> 65.6us (1.15x). Per-element times (~0.1ns) show the fold is
fully inlined and auto-vectorized in this benchmark; the win is the
per-lane subtract dependency of len - i - 1 vectorizing worse than a
counting index. With an opaque, non-inlinable closure the difference
shrinks accordingly.

Also adopts #3784's test pinning the reversed index/element pairing,
which a miscounted index would break.

Codex CLI review (xhigh, first-round sign-off): (index, element)
pairing verified as (0,len-1)..(len-1,0) against the documented
reverse-range and simultaneous-update semantics (f receives the
pre-increment index); the pairing-test trace recomputed to 30120210;
raise-polymorphism and the nobreak return intact; benchmark ratios
recomputed (1.33x/1.21x/1.15x) and microbenchmark-scoped.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Codex CLI <codex@openai.com>

2 of 2 new or added lines in 1 file covered. (100.0%)

16304 of 17969 relevant lines covered (90.73%)

332567.99 hits per line