Measuring progress
Capture compiler-phase timings without confusing them with generated program performance.
A compiler has two different speeds: the time it spends compiling and the time its output spends running. Improving one can make the other worse. Track both before choosing an optimization strategy.
The current bench/run.py suite measures scanning, parsing, individual passes, text/C/LLVM
emission and interpretation at several synthetic input sizes. Reports in
bench/reports/ retain repeated samples, medians, machine details, compiler,
source revision, source hash and binary hash. bench/README.md gives the exact
release-build command. Every subprocess has a timeout; a failed phase stops the
capture instead of becoming a zero-time result.
Compare the same workload and build mode on the same machine. Keep raw samples: a small median change inside a large timing range is weak evidence. Source hashes identify uncommitted work, since a report cannot contain the hash of the commit that will itself contain that report.
LLVM text emission is not LLVM compilation. VM interpretation is not native program speed. These first reports therefore make no claim about reaching 90% of LLVM. A runtime comparison must compile equivalent kernels through both backends, validate results and printed output, then measure repeated runs with matching target and optimization settings.
Read parser performance for the stage breakdown, implemented fixes, and the proposed on-demand DFA and pruned SSA work.
Binary archives and linking
The generated report bench/reports/2026-09-22-binary-merge.json adds bounded
binary loading, serialization, and merging to the phase suite. Seven independent
release samples produced these medians:
| Instructions per input | Serialize | Load and validate | Merge two inputs |
|---|---|---|---|
| 203 | 0.019 ms | 0.040 ms | 0.141 ms |
| 1,003 | 0.078 ms | 0.174 ms | 0.602 ms |
| 2,003 | 0.154 ms | 0.352 ms | 1.169 ms |
| 20,003 | 1.448 ms | 3.355 ms | 13.480 ms |
Merging includes deep copies, validation, ID remapping, and final verification. Its output contains twice the listed instruction count. Fixture construction and result destruction are outside the measured interval. These are synthetic instruction-heavy units; they do not establish scaling for large symbol/type tables or a generated-code speed ratio against LLVM.
Potential next improvements are a direct cloning visitor instead of encoding and decoding input copies, a streaming archive reader, and structural type hashing. Profile representative multi-file programs before trading the current explicit ownership and validation boundaries for those changes.