Typing latency benchmarks across modern code editors

Benchmarks | Koi Editor

-->

Benchmarks

Last updated: 2026-07-29

This page contains documented and repeatable benchmarks comparing Koi Editor with other popular code editors. All editors are tested on the same hardware using identical files and settings wherever possible. Benchmarks are updated periodically as new editor releases become available.

Typing latency

Large file performance

Editor versions

Final notes

FAQ

Unless otherwise noted, all editors were tested with syntax highlighting enabled using their built-in language support. Individual benchmarks may include different editors depending on compatibility with the test file and whether comparable functionality is available. An editor may be omitted from a benchmark if it cannot be tested under comparable conditions.

Typing latency

Lower latency means the editor responds more quickly to each keypress. Higher latency can make editing feel less responsive, especially when typing continuously in large source files.

All measurements in milliseconds. Median represents the typical keypress latency, while the percentile metrics capture occasional slower frames that affect perceived responsiveness.

sqlite3.c

Editor Median p95 p99 Max Tail Spread vs Fastest (p95)

Koi 14.8 17.8 18.1 18.2 3.0 1.00x

Vim 15.5 19.4 20.7 46.9 3.9 1.09x

TextMate 25.6 28.8 30.5 31.1 3.2 1.62x

VS Code 26.4 35.5 39.4 39.9 9.1 2.00x

Zed 36.9 45.7 49.2 49.9 8.8 2.57x

Neovim 44.1 48.2 51.4 54.6 4.1 2.71x

Sublime Text 28.3 48.6 55.8 56.8 20.3 2.73x

Emacs 58.5 87.6 90.7 97.0 29.0 4.93x

BBEdit 27.3 91.1 98.4 101.5 63.8 5.13x

Notes:

VS Code performs well in this typing benchmark, but other editing operations, such as indenting many lines, were noticeably slower and occasionally caused the editor to become temporarily unresponsive.

gcc.c

Editor Median p95 p99 Max Tail Spread vs Fastest (p95)

Koi 14.9 18.3 19.5 23.4 3.3 1.00x

Lite XL 22.8 29.1 46.2 130.9 6.3 1.59x

VS Code 19.1 30.1 34.5 37.2 11.0 1.65x

Neovim 44.3 47.1 51.4 54.4 2.8 2.58x

Vim 43.2 47.6 49.0 49.4 4.5 2.61x

Sublime Text 32.1 52.4 56.4 63.3 20.3 2.87x

Xcode 45.4 53.3 61.8 64.1 7.9 2.92x

Zed 72.9 100.9 105.7 106.9 27.9 5.52x

Emacs 95.4 127.9 130.7 131.0 32.6 7.00x

BBEdit 25.9 317.7 326.3 327.1 291.7 17.39x

Notes:

Lite XL and Xcode were added to this benchmark.

Lite XL was tested with its default configuration, which disables code folding for files of this size.

TextMate and CodeEdit could not open the test file.

JetBrains CLion opened the file in read-only mode ("The file is too large: 21.86 MB.").

VS Code was faster in this benchmark than with the smaller sqlite3.c file. The gcc.c file exceeds VS Code's large-file threshold, which activates special optimizations and may disable or reduce expensive editor features. The lower typing latency observed here should therefore not be interpreted as a direct indication that larger files are inherently faster to edit.

Test environment

Component Value

Hardware Mac mini M2 Pro, 16 GB RAM

Operating System macOS 15.7.5

Display 60 Hz

Test files sqlite3.c (151,639 lines), gcc.c (753,821 lines)

Configuration Default settings with syntax highlighting and line numbers enabled. Folding was enabled where supported, some editors automatically adjust features for very large files.

vim +'syntax on | set number autoindent smartindent cindent foldmethod=syntax foldlevel=99 complete=.,w,b,u,t,i'

nvim \ +'set ft=c number autoindent smartindent cindent complete=.,w,b,u,t,i' \ +'syntax on' \ +'set foldmethod=syntax foldenable foldlevel=99 foldlevelstart=99' \ +'normal! zR' \

Methodology

Typing latency was measured using keypress.sh, which records the time between a simulated keypress and the editor presenting the updated frame on screen. Each benchmark consists of 200 measured keypresses, repeated under the same conditions.

Measurements shown are median, p95, p99, maximum latency, and tail spread (p95 – median), which indicates how consistent latency remains under heavier load.

Results were measured on a 60 Hz display, where one refresh interval is approximately 16.7 ms. Since the benchmark measures keypress-to-display latency, values naturally cluster around multiples of the display refresh interval (16.7 ms, 33.3 ms, 50 ms, and so on). Lower latency therefore means the editor more consistently completes processing within fewer display frames.

Large file performance

Last updated: 2026-07-28

Large file performance measures whether an editor can open and navigate very large files while remaining responsive.

Editor 5M lines 10M lines 15M lines 20M lines

Koi

Vim

Neovim

Sublime Text

VS Code Degraded

TextMate Degraded

Zed

BBEdit

Emacs

Legend: remained interactive throughout testing. Degraded opened the file but editing performance was substantially impaired. – could not be tested or did not remain usable.

Notes:

Sublime Text remains responsive but takes noticeably longer to open very large files and did not complete loading the 20M-line...

Typing latency benchmarks across modern code editors

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

The Anatomy of an AI-Native Org