Use Cases · View as Markdown

Zero-latency typing

What is typing latency? ⋅ How fast is Koi? ⋅ What makes an editor slow? ⋅ Is zero-latency typing actually possible?

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 a text editor feels.

Opening a file happens once.

Indexing happens occasionally.

Typing happens all day.

Koi is designed to keep that path short.

TL;DR

Fast typing is not just about achieving a low latency number on an empty document. It is about keeping the path from input to display short as syntax highlighting, multiple views, completion, and increasingly large documents add work around it.

Koi measured approximately one 60 Hz display interval at P95 in our standard source-file benchmarks and remained below 40 ms P95 in the 20-million-line test.

What is typing latency?

A keypress has to travel through the editor before it becomes a visible character. Depending on the editor, that can involve input handling, document updates, syntax highlighting, parsing, diagnostics, completion, plugins, layout, rendering, and finally presentation by the display.

The total time between input and the updated frame appearing is typing latency.

On a 60 Hz display, a new frame can be presented approximately every 16.7 ms. That makes roughly one display interval a useful target: process the input quickly enough that the result can appear on the next available frame.

Why P95 matters

P95 matters because average latency can hide slow frames.

Consider an editor where most keypresses appear in 16 ms, but every so often one takes 80 or 100 ms. Its average can still look reasonable, while the occasional delay is noticeable during typing.

This is why our benchmarks primarily use P95 latency. P95 is the latency within which 95% of measured keypresses were displayed. We also measure median, P99, maximum latency, and tail spread:

Tail spread = P95 − median

A small tail spread means the editor responds consistently rather than alternating between fast and slow frames.

How fast is Koi?

We measure Koi using Keypress.sh, which records the time between a simulated keypress and the updated frame being presented on screen. One of the test documents is gcc.c, a 753,821-line C source file.

Editor	Median	P95	P99	Max	Tail Spread
Koi	14.5 ms	16.6 ms	17.3 ms	17.7 ms	2.2 ms
Xcode	25.2 ms	27.6 ms	29.5 ms	30.8 ms	2.3 ms
Sublime Text	20.2 ms	30.4 ms	31.6 ms	31.6 ms	10.2 ms
TextMate	40.7 ms	42.6 ms	43.3 ms	43.5 ms	1.8 ms
Vim	43.2 ms	47.8 ms	48.8 ms	48.9 ms	4.6 ms
Neovim	49.7 ms	52.9 ms	56.5 ms	57.8 ms	3.2 ms
Zed	43.2 ms	57.3 ms	64.8 ms	65.0 ms	14.1 ms
Emacs	87.0 ms	118.3 ms	121.3 ms	122.0 ms	31.3 ms
Lite XL	18.9 ms	119.8 ms	171.2 ms	201.9 ms	100.9 ms
VS Code	27.9 ms	171.9 ms	178.9 ms	181.4 ms	144.0 ms
BBEdit	226.8 ms	301.6 ms	307.1 ms	517.8 ms	74.8 ms

Koi measured 16.6 ms at P95, approximately one refresh interval on the 60 Hz test display.

The full benchmark also tests a 151,639-line source file, dual-pane editing, files up to 20 million lines, memory usage, and editor usability. See Benchmarks for the complete methodology and results.

What makes an editor slow?

Typing into a text buffer is cheap, but everything surrounding it may not be. A modern code editor can perform work after every change:

• syntax highlighting
• parsing
• diagnostics
• autocomplete
• bracket matching
• document symbols
• minimap updates
• plugins and extensions
• language-server communication
• layout and rendering

None of these features is necessarily expensive by itself. The problem is putting too much synchronous work between the keypress and the next rendered frame. This is where editor latency and noticeable typing lag can start to appear.

Large files expose the difference

A small file can hide inefficient editor architecture. At a few hundred lines, rebuilding a data structure or rescanning more text than necessary may still finish before the next frame.

At hundreds of thousands or millions of lines, the same work becomes visible. In our large-file tests, Koi measured:

File size	P95 typing latency
1M lines	19.3 ms
5M lines	20.5 ms
10M lines	31.0 ms
20M lines	37.3 ms

The goal is for that increase to remain controlled rather than suddenly turning into hundreds of milliseconds of delay. The complete large-file benchmark, including memory consumption and results from other editors, is available on Benchmarks.

How Koi approaches latency

Koi is designed around the keypress-to-render path first. This is the hot path for typing in an editor.

Work required to display an edit is kept separate, as much as possible, from work that can happen afterwards. Reducing work on this path gives the largest and most predictable latency improvements.

Syntax highlighting is kept minimal to avoid unnecessary parsing, backtracking, multiple passes, and other hot-path work.

Multiple views share the same underlying document rather than creating independent copies of the editing state. Adding another view of the same file should not require duplicating the work of editing it. This also shows up in the benchmarks: Koi measured 16.6 ms P95 with one view of the 753,821-line file and 16.4 ms with two.

Is zero-latency typing actually possible?

No display has literally zero input latency. The name describes the goal: make editor-induced latency small enough that the editor itself stops being the noticeable bottleneck.

On the 60 Hz system used for our tests, one frame lasts about 16.7 ms. Koi measured 16.6 ms P95 keypress-to-display latency on the 753,821-line test, approximately one display interval. At that point, further reductions can be hidden by the refresh cycle of the display itself.

See Benchmarks for the complete results and results of other editors.