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.0/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 release above, the same one the terminal itself ships from. 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.