Zero-latency typing

Test methodology ⋅ Results ⋅ Large files ⋅ Why latency matters ⋅ Takeaway

Typing latency is the time between pressing a key and seeing the result on screen.

It is one of the most direct measures of how responsive an editor feels, but relatively few editors publish measurements for it. Startup time, indexing, and file-opening speed matter too, but once the editor is open, typing latency is what you interact with continuously.

Test methodology

Measurements were taken using Keypress.sh, which measures the time from a simulated keypress until the updated frame is presented on screen.

Graphical applications were launched directly from their bundled Mach-O executables. Inter-key delays were randomized to avoid giving editors a predictable synthetic typing cadence.

On a 60 Hz display, a new frame can be presented approximately every 16.7 ms. Results therefore tend to cluster around display intervals such as 16.7 ms, 33.3 ms, and 50 ms.

Why P95?

The median describes a typical keypress. P95 describes the latency within which 95% of measured keypresses were displayed.

This makes P95 useful for finding the occasional slower frames that can make an otherwise fast editor feel inconsistent.

Tail spread is P95 minus the median. A smaller spread means latency remains more consistent across the test.

Results

sqlite3.c

The first test uses sqlite3.c, a 151,639-line C source file.

Koi measured 16.3 ms at P95, close to one refresh interval on the 60 Hz test display. With the same file displayed in two panes:

Koi measured 16.0 ms P95 with the document visible in both panes.

gcc.c

The second test uses gcc.c, a larger 753,821-line C source file.

Koi measured 16.6 ms at P95. For comparison, Sublime Text measured 30.4 ms, Zed 57.3 ms, VS Code 171.9 ms, and BBEdit 301.6 ms. With the same document displayed in two panes:

Koi measured 16.4 ms P95 with the document displayed in two panes.

Large files

The same measurement becomes more interesting as file size increases. The table below shows P95 typing latency for each file size that passed the large-file usability benchmark:

Koi measured 20.5 ms P95 at 5 million lines and 37.3 ms at 20 million lines. See Benchmarks for memory usage, usability criteria, editor configurations, and the complete large-file results.

Why latency matters

Typing is one of the few operations an editor performs continuously while you work.

Every keypress can trigger highlighting, parsing, diagnostics, completion, rendering, plugins, and other editor work. As files become larger and more features become active, that work can begin to show up as delayed or inconsistent frames.

Low median latency is useful, but consistency matters too. An editor that usually responds quickly but periodically misses several frames can still feel noticeably less responsive.

Koi is designed to keep the path from keypress to rendered text short and predictable, even as document size increases.

Takeaway

On the 60 Hz test system, Koi measured approximately one display interval at P95 in both source-file tests:

• sqlite3.c: 16.3 ms
• sqlite3.c, dual pane: 16.0 ms
• gcc.c: 16.6 ms
• gcc.c, dual pane: 16.4 ms

In the separate large-file benchmark, P95 remained at 37.3 ms with a 20-million-line file.

The goal is not simply to produce a low number in a small-file benchmark. It is to keep typing latency low and consistent as the amount of work around the editor increases.

Related:

• Code Editor Performance Benchmarks
• Koi vs. Zed
• Koi vs. Sublime Text
• Koi vs. BBEdit