Performance

python3 tools/bench-phase1.py
cargo test --release -p kalem-tui --test latency -- --ignored --nocapture
cargo test --release -p kalem-ui --test latency -- --ignored
cargo bench -p org-syntax --bench parse

• tools/bench-phase1.py builds both release binaries and runs them as a user would. The editors quit after their first frame when KALEM_EXIT_AFTER_START is set; times are the median of three runs, memory is the peak resident size. The documents are the Org manual repeated to 1 MB and 10 MB, and to 100 MB as a .txt file.
• The terminal latency test types 400 keys in the middle of the Org manual and draws a frame after each, into ratatui's test backend. It also saves a 10 MB document five times.
• The graphical latency test does the same in gpui's test platform with the system's text system: from the key to the painted frame. The GPU's work and the wait for the display are not included.
• The parser benchmark measures full parses and an incremental reparse after a keystroke in a paragraph.

Measured on 2026-09-28 on an Apple M1 Max (macOS 15.1, Rust 1.98.1), with other work running on the machine.

Every target is met but three: both binary sizes (roadmap R2.1; CI's binary size job fails a change that grows either past its ceiling in tools/binary-size.txt) and the LaTeX project keystroke, a fifth over it on this machine. An edit that only moves the events of a file (typing in a paragraph, the common keystroke) moves the last model's positions instead of numbering the project again; the edit's region comes from the shared nodes of the two trees, and a test of random edits checks the result against a model built from scratch (latex-model/tests/incremental.rs). The files of the project are trusted from disk for a second between checks.

At 10 MB the opening meets its target. A keystroke there takes 78 ms: the incremental parse and the edit take 9.9 ms, but the screen rebuilds the document model (41 ms) and the blocks scan the whole text for their delimiters (26 ms); both grow with the file, and making them incremental is left until a document that size is a real case.

The binary size targets include math fonts, still to come (T2.2.1), so the gap will grow before it shrinks.

A full parse of the Org manual takes 42 ms (about 20 MB/s). Opening an Org document is mostly this parse, so the tightest targets are the ones that parse a 1 MB file: check, fmt and opening in the graphical editor. What made them fit:

• Parser. Element regexes run only on lines that start with a byte they can match. Emphasis closers are indexed from the marker bytes, and block ends from one pass per leading byte. Word boundaries between ASCII characters skip the script table, and plain links check the first byte of the link types.
• Formatter. kalem fmt parses once and maps positions through the table and tag alignments, where it used to parse four times.
• Graphical editor. The file given on the command line is read and parsed on another thread while the window system starts. Only a launch from an app bundle without a file waits for the files the system opens.
• Large files (T2.7a.3). A keystroke in a 100 MB plain text file costs 2.7 ms at the median and 14 ms at the 99th percentile (cargo run --release -p kalem-core --example text_timing FILE.txt), under a frame, so plain text mode keeps contiguous text with its line index rather than a rope or piece table (T1.3.1a). Files over 4 MB are colored a window of 400 lines at a time, from a fresh parser state 200 lines before it (kalem_highlight::Windowed), and a line longer than 16 KiB shows the 16 KiB around the cursor with … for the rest (kalem_core::view::plain_line_view), in every mode.

The CI job for benchmarks (a benchmark per target, regressions blocking a pull request) is not set up yet.