Starling Terminal

Speed — thirteen tests at steady state, three platforms

Hover any row for the raw seconds. Sustained is the regime that matters, and it is not always the flattering one — the two workloads ghostty wins in ten-second bursts (light and dense cells, 0.85× and 0.69× short-range) converge to parity here, but ghostty also gains nothing back: its Linux unicode throughput halves at scale (184 to 97 MB/s) while ours sheds only a quarter (228 to 173 MB/s). Across all three platforms and all thirty-nine cells above, the one test the other side keeps by more than noise is the Linux ascii cat, by ~6% — ghostty's io_uring read path gets under the read(2) floor ours sits on. macOS has no io_uring, and the cat flips to us; on Windows every test is a win.

The cost — CPU and memory for the same work

On Windows the CPU figures include the console host, which does a large share of the work there and would flatter us if left out; the memory gap is the widest of the three platforms — 73 MB against 1,026 MB after the same ten workloads, a figure Windows Terminal reproduces across machines. CPU-seconds are otherwise charged to the terminal's own process, read around each workload. Memory is flat on our side of all three platforms — the same resident set no matter how much has been drawn — while the other side's grows with load; only the light Linux legs leave ghostty below us.

The setup

Who: the ghostty nightly on Linux and macOS, configured onto our Roboto Mono at our cell metrics so both terminals raster the same pixels; Windows Terminal Preview 1.25 on Windows, in its own process (the stable build hands new windows to whatever Windows Terminal is already running). Where: Linux — Ryzen 7 8845HS, GNOME/Wayland; macOS — MacBook Pro on macOS 26.6.1; Windows — a Ryzen 7 8845HS laptop with a Radeon 780M, the first Windows round on real hardware rather than a VM. Grids verified on both sides before every leg: 47×201 on Linux and macOS, 40×120 on Windows. How: every test at steady state — each workload repeated until the slower side sustains one to two minutes (~159 GB of escape-sequence traffic per terminal on Linux, ~30 GB on macOS), the cats exact 500,000,000-byte corpora, DOOM-Fire run to 150,000 frames three times over. Both sides measured back to back on one machine; bars are multiples of the other terminal's pace on a log scale, so a 2× win and a 2× loss have equal length.

The rounds behind the numbers

The Linux and Windows legs ran on 30 Hz displays, so raw walls compare within a platform; the ratios carry. The macOS numbers are the rerun taken after the macOS 26.6.1 upgrade — which moved nothing beyond run noise against the same-day pre-upgrade round. The Windows round runs the console on the UTF-8 code page, so the unicode workloads draw real CJK text rather than the mojibake every earlier VM round was unknowingly measuring, and a fixed compute loop timed inside every leg proves both sides saw the machine in the same state; the archived VM rounds remain, but they measure the legacy code page. The raw runs are checked in at docs/perf (Windows: -windows-realgpu-2026-08-16; Linux: -2026-08-14-long; macOS: -macos-2026-08-14-postupgrade, confirmed against -macos-2026-08-14-long; short range: -2026-08-13-atlas and -macos-2026-08-13-samefont).

curl -fLO https://github.com/starling-build/starling/releases/download/sdk-v0.3.1/starling-create
chmod +x starling-create
./starling-create myterm
cd myterm && swift run -c release

Those four lines are the same on Linux, macOS and Windows — on Windows in Git bash, which is where a curl instruction lands anyway. starling-create is an asset on the SDK release above — a different release from the terminal's, which is why the tag says sdk-. It checks your toolchain, fetches the SDK bundle for the machine it is run on — the framework plus the engine binaries it links against, 14 MB on macOS, 17 MB on Windows, 23 MB on Linux — and writes the SwiftPM project around it. No repo to clone, no engine checkout, no Flutter install; a Swift toolchain is the only prerequisite. The SDK is cached once under ~/.starling/sdk and shared, so the second project costs no download; --template app scaffolds a plain window instead of a terminal, and --sdk takes a URL or a local archive when you want a bundle other than the release's. What it writes is this, and this is the whole app:

import ExampleHost
import Flutter

let session = TerminalSession()
session.startShell()

runExampleApp(title: "Terminal", width: 940, height: 620) {
    TerminalView(session: session)
}

That is the same widget the films above run on, and the same one the shipped terminal is built from — the release archives are assembled against this SDK bundle, not against a private tree. The workspace is it with geometry around it — splits, frames and a cover flow, and no terminal code of its own.