Benchmarks

How fast ashlar is, how that was measured, and how to reproduce it. Machine: Apple M5 Pro (15 cores), 24 GB, macOS. All builds are release builds, run through memgate.

Two kinds of numbers appear below:

• Quiet measurements were taken with nothing else heavy running. Comparisons use only these.
• The full-suite snapshot (cargo xtask bench, at the end) ran while other builds shared the machine. Its absolute timings are inflated, often by 2–4×. Allocation counts, sizes and frame counts are not affected by load.

Running them

cargo xtask bench                                   # every `perf_*` test; writes target/bench/bench.{json,md}
cargo xtask bench --filter plain_scroll             # one group
cargo xtask bench --repeat 3 --compare base.json    # fails on a >5 % regression against a saved run
cargo xtask launch --runs 9                         # launch → window → first present, opens real windows
cargo xtask launch --memory                         # idle footprint and peak after a settle

A perf test is a #[test] #[ignore] fn perf_* that prints bench: <metric> <value> <unit> lines (see docs/architecture.md, “Performance gate”).

Against a comparable native Rust UI framework

Measured on 2026-11-10, both frameworks in the same session with the same tools:

• a launcher that times spawn → window, plus ps and vmmap for idle cost
• each framework’s own benchmark for the same scrolling workload: a plain list of 1,000 rows of 32 pt in a 760×800 pt viewport at 2×, with 120 warm-up frames and then 480 wheel steps of 12 pt at 120 Hz, reversing halfway

The other framework draws with its own GPU renderer and a retained element tree. ashlar draws with egui.

What each scroll number covers:

• ashlar’s is the thread CPU of the egui pass plus tessellation.
• The other framework’s is the thread CPU from wheel dispatch to its draw list.
• Neither includes GPU submission.

Lists should be virtualized (VirtualList). Then the cost does not depend on the row count at all: 0.035 ms at 1k or 100k rows, measured quiet.

Idle memory, explained: ashlar’s idle footprint is about 40 MB (94 MB peak) for a window that has never been covered, and about 66 MB (about 193 MB peak) once it has been covered, minimized or moved to another Space, even briefly right after launch. At that point macOS maps two swapchain images it shares with the window server into the process (about 19 MB), and Metal allocates a second set of blocks. This happens with any present mode or frame latency, so it is not something ashlar’s own settings cause. cargo xtask launch --memory launches 5 times and reports both groups. The other framework’s 29 MB was measured the same way. Whether its windows avoid the effect, or were simply never covered during the measurement, is not known.

Before and after the 2026-11 improvement work

All quiet measurements. “Before” is commit 393afe0.

Component costs (quiet)

Full-suite snapshot (loaded machine)

This is cargo xtask bench at imp 30e3264, run while five other builds were compiling. Use it to see which metrics exist, not for absolute timings: run it on a quiet machine before comparing.