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

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

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

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

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' \
    <path_to_file>

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.

Download raw measurements (CSV)

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.

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 file.
• VS Code and TextMate opened the 5M-line file but became unusable with syntax highlighting enabled.
• Emacs warns before opening very large files, then became unresponsive after confirmation.

Test environment

vim \
    +'syntax on' \
    +'filetype plugin indent on' \
    +'setlocal filetype=python' \
    +'set number autoindent expandtab shiftwidth=4 softtabstop=4 tabstop=4 complete=.,w,b,u,t,i' \
    <path_to_file>

nvim \
    +'syntax enable' \
    +'filetype plugin indent on' \
    +'setlocal filetype=python' \
    +'set number autoindent expandtab shiftwidth=4 softtabstop=4 tabstop=4 complete=.,w,b,u,t,i' \
    <path_to_file>

Methodology

Each editor is opened with the test file and allowed to finish loading. Editors that failed to become interactive within a reasonable amount of time were considered unsupported at that file size. The file is then tested by jumping to the beginning and end, scrolling, indenting multiple lines, and inserting new lines.

An editor is considered to support a file size if it remains responsive throughout this process without requiring force quit or becoming unusable.

Editor versions

Final notes

• Benchmarks are performed on a single hardware and software configuration.
• Results may vary on different operating systems or hardware.
• Editors are tested using their default editing experience unless otherwise stated.
• Benchmark pages are updated as significant editor releases become available.

FAQ

Why are Vim and Neovim tested with syntax-based folding enabled?

The goal of these benchmarks is to compare practical editing configurations rather than the fastest possible text insertion.

Vim and Neovim were tested with syntax highlighting, line numbers, automatic indentation, completion sources, and syntax-based folding enabled to provide functionality broadly comparable to the graphical editors.

Disabling syntax-based folding improved typing latency, but also removed functionality that remained enabled in the comparison configuration.

Why compare terminal editors with graphical editors?

These benchmarks measure end-to-end visible responsiveness rather than isolated editor-engine performance.

Terminal and graphical editors use different rendering pipelines, but each editor was tested in its normal user-facing environment. The measured latency therefore reflects the experience users encounter during normal editing.

Were different syntax highlighting implementations used?

Yes.

Each editor was tested using its built-in language support. Different editors use different implementations, including regular-expression syntax highlighters, Tree-sitter, TextMate grammars, and custom lexers.

The benchmarks compare equivalent visible functionality rather than identical internal implementations.

Were folds expanded during testing?

Yes.

Syntax-based folding remained enabled where configured (to trigger the behind-the-scenes fold level computations), but all folds were expanded during typing measurements.

Were the editors warmed up before measurement?

Yes.

Measurements began only after the editor became responsive and the visible region had been fully highlighted. Typing was measured after the initial loading work had completed.

Were all editors configured identically?

No.

Editors were tested using their default editing experience wherever possible.

Features such as fonts, rendering backends, syntax engines, scrolling behavior, and large-file optimizations differ between editors and were not modified unless required to enable comparable functionality.

The goal is to compare the editing experience users receive from each editor, not to normalize every implementation detail.

How were the latency statistics calculated?

Each benchmark records 100 keypress appearances and 100 keypress disappearances.

The two lowest and two highest measurements are discarded to reduce the influence of unrelated system activity, leaving 196 samples for the reported statistics.

Median, p95, p99, maximum latency, and tail spread (p95 − median) are calculated from those remaining samples.