[asp24]

Applies the approach of #6 to the other three functions that walk the tape one element at a time: Advance, NextElementBytes and AdvanceIter. Each now handles the common case in one straight run. NOPs, the end of the tape and every error go to the code the function had before, which runs from the start, so those cases behave as they did.

Commits

1. Keep the object walk's stack between iterations. IterRead/*/objects regrew its stack on every call, up to 6 MB per operation on canada. The rows mostly measured the garbage collector, with every Iter copied through a write barrier while it marked. The same binary moved by tens of percent between runs, and the first measurement of this change showed a regression that was not there. The stack is now kept between calls and allocates nothing: citm_catalog 365 → 234 µs, canada 1943 → 979 µs.

2. Benchmark reading through AdvanceIter. ForEach and Array's helpers read through it, and no benchmark called it. New rows: IterRead/*/iters.

3. Stop NextElementBytes on two corrupt tapes, found by the differential test.

   • A NOP of zero sent it back to the same entry by recursion until the stack ran out. That is a fatal error, which a caller cannot recover from.
   • A container ending before its start, which Deserialize accepts when the stored distance is zero, moved the object back.
   • Both are now errors, as they already were in AdvanceIter. The parser never produces either.

4. Advance: one straight path, as AdvanceInto has.

5. NextElementBytes: one straight path, with no switch on either tag.

6. AdvanceIter: one straight path. It also stops reading back what it has just written: *dst = *i read off and addNext in one 16-byte load right after the two 8-byte stores that wrote them. The store queue cannot forward that, so the load waited for both stores to reach the cache. That one load took half of the function's time.

7. README. The list of differences from upstream gains reading. Against v0.4.5, measured side by side with BenchmarkIterRead added to its tree, all 28 rows are faster, geomean -31.7%: walk -30% to -39%, typed -25% to -31%, objects -12% to -22%, iters -43% to -51%.

Time, each commit against its parent

Measured with benchmarks/perfgate/ab.sh: four code layouts a side, six rounds, on twelve cores.

commit	rows	change	other IterRead rows
Advance	objects	-3.1% to -13.2%, every document	within the control
NextElementBytes	objects	-4.5% to -13.4%; canada, almost no keys, -0.1%	within the control
AdvanceIter	iters	-43.6% to -50.5%, every document	within the control

The read group from commit 3 to the end: geomean -13.0% (control +2.1%). ParseNDReuse and the payloads are within the control.

Testing

advance_diff_test.go keeps the previous code of each function as a reference and walks both in lockstep. Walks start from every tag on:

• the corpus;
• the corpus with deletions, which leave NOPs;
• the corpus cut short;
• the corpus with container ends pointing backwards or past the tape;
• hand-made edge tapes.

Every field of the Iter, dst and the Object is compared, along with the result, the error and any panic. Seeding faults into the new code checked the test: every one was caught, except one that is equivalent by construction (end < len for end <= len, which only sends the edge case down the slow path).

🤖 Generated with Claude Code