Performance

Ubiquitty consistently outperformed kitty, Ghostty, Alacritty, Terminal.app, and iTerm2 across the tested macOS throughput workloads.

A parser throughput measurement, a frame-building cost and input-to-display latency answer different questions. Benchmark records identify the workload, configuration and environment used for each measurement.

Measure the workload

The benchmark guide covers the native harnesses and their commands. Baselines are machine-specific and kept outside the repository, in the directory named by UBIQUITTY_PERF_BASELINE_DIR; each records its machine, build and workload.

• Parsing: terminal bytes through the parser and screen model.
• Rendering: frame capture, glyph work, instance building and presentation are separate costs.
• History: reflow, search and storage depend on line count and content.
• Synchronization: bytes transferred, update latency and reconnect behavior depend on the changed state and link.
• WebAssembly: compare the same workload and compiler settings, not unrelated native and browser examples.

Run timing-sensitive measurements on an otherwise quiet machine. Record the commit, hardware, OS, compiler, optimization settings, input corpus and repetition method. Report distributions for latency and distinguish warm caches from cold runs.

Storage and visible work

The host folds cold history blocks into a lossless row representation during maintenance, after I/O and frame delivery. It processes at most one eligible block per maintenance tick and avoids a session with readable PTY input. This changes storage, not line identities or the content a client sees.

Screen updates track changed rows; a quiet pane does not require rebuilding all of its text. Synchronized-output brackets let a program publish a completed screen rather than intermediate drawing steps.

Interpreting results

Compare reproducible workloads with the same settings, and retain the raw output alongside a summary. The repository’s benchmark tools provide the starting point.