esp32p4.git/experiments/length-ReleaseFast-lineSpan.csv, branch mainESP32-P4https://git.0x4200.cafe/esp32p4.git/atom?h=main2026-08-25T22:29:22ZMeasure all four configurations; the code fix is worth nothing here, the flag is worth 21%2026-08-25T22:29:22ZGabriel Schneidergbrls@0x4200.cafe2026-08-25T22:29:22Zurn:sha1:341a9fe36840ec227284b6fac35e247d5d20ac18
The obvious question after the last commit was what it did on the actual target. The
answer is nothing, and the useful part is that the same run says what DOES work.
Four builds on the die, 5 document lengths x 7 trials each:
configuration fixed per char at 160 vs base
ReleaseSmall 16.99 ms 54.3 us 25.56 ms 1.00x
ReleaseSmall+lineSpan 17.10 ms 54.0 us 25.63 ms 1.00x
ReleaseFast 14.85 ms 34.7 us 20.30 ms 0.79x
ReleaseFast+lineSpan 14.88 ms 34.2 us 20.25 ms 0.79x
The edit-path change is invisible in BOTH modes, and ReleaseFast+lineSpan is
indistinguishable from ReleaseFast alone. The optimisation mode is the whole of the
difference, which is what Experiment 3 predicted: the edit path is 220 us of a 17 ms
keystroke, so making it cheaper cannot move the total, while the mode makes the
RENDERER faster and the renderer is where the time is.
`experiments/report.typ` gains that table and the reason the four-way comparison
exists rather than four indistinguishable lines on figure 1.
The board is now flashed with the default build, which as of the pin next door means
ReleaseFast: 809,552 B of the 1,536,000 B partition, 53%.