Code Editor Performance Benchmarks

Updated on August 11, 2026 by Michael

This page contains documented and repeatable benchmarks comparing Koi Editor with other popular code editors.

• Typing latency
• Large file performance
• Editors tested
• Final notes
• FAQ

All editors are tested on the same hardware and test files, using comparable settings wherever practical. Benchmarks are updated periodically as new editor releases become available.

Unless otherwise noted, syntax highlighting was enabled using each editor's built-in language support. Editors may be omitted when the test file or equivalent functionality is unsupported.

Download raw measurements

Commit 4ed1040 added randomized inter-key delays to Keypress.sh. This prevents editors from benefiting from a fixed synthetic typing cadence and produced results that more closely match observed continuous-typing responsiveness.

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. Relative P95 values are calculated from the unrounded measurements.

Graphical applications were launched directly from their bundled Mach-O executables. This avoids a repeatable macOS input-to-display latency difference associated with LaunchServices launches, see FAQ: Why are these results different from earlier benchmark versions?.

Single pane displays one view of the test file.

Dual pane displays the same document simultaneously in two editor panes while typing in one pane.

sqlite3.c

Single pane:

Dual pane:

Notes:

• BBEdit had autocomplete disabled because it could not be reliably overridden in the tested configuration.
• TextMate does not provide autocomplete while typing in the tested configuration.
• Vim, Neovim, and Emacs were tested without automatic completion popups.

gcc.c

Single pane:

Dual pane:

Notes:

• Sublime Text was tested with autocomplete disabled because enabling it made editing the larger test file unusable.
• TextMate does not provide the dual-pane configuration used by this benchmark, and initial syntax highlighting of the larger file was very slow.

Test environment

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.

Editor configurations

Vim config file:

" ~/.vimrc

syntax on

set number
set autoindent
set smartindent
set cindent

set foldmethod=syntax
set foldlevel=99

set complete=.,w,b,u,t,i

set nowrap
set mouse=a

Emacs config file:

;; ~/.emacs.d/init.el

;; Syntax highlighting
(global-font-lock-mode 1)

;; Line numbers
(global-display-line-numbers-mode 1)

;; C mode
(add-to-list 'auto-mode-alist '("\\.c\\'" . c-mode))
(add-to-list 'auto-mode-alist '("\\.h\\'" . c-mode))

;; C indentation
(setq c-default-style "linux")

;; Folding
(add-hook 'c-mode-hook #'hs-minor-mode)

;; No word wrap
(setq-default truncate-lines t)

;; Completion
(setq completion-auto-help 'always)
(setq completion-cycle-threshold nil)

Neovim config file:

-- ~/.config/nvim/init.lua

vim.opt.number = true
vim.opt.wrap = false
vim.opt.mouse = "a"

vim.opt.autoindent = true
vim.opt.smartindent = true
vim.opt.cindent = true

vim.opt.complete = ".,w,b,u,t,i"

vim.opt.foldmethod = "expr"
vim.opt.foldexpr = "v:lua.vim.treesitter.foldexpr()"
vim.opt.foldlevel = 99
vim.opt.foldlevelstart = 99
vim.opt.foldenable = true

vim.api.nvim_create_autocmd("FileType", {
    pattern = { "c", "cpp" },
    callback = function()
        vim.treesitter.start()
    end,
})

Large file performance

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

Responsive

Degraded Opened, but editing was substantially impaired

– Did not become 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. Large-file testing is qualitative rather than a timed loading benchmark. Editors that failed to become interactive during the test session were recorded as unsupported.

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.

Editors tested

The benchmark focuses on general-purpose code and text editors available on macOS. IDEs specialized around particular languages or project environments are excluded. C is used for the primary tests because it is widely supported across the editors tested.

The versions listed above are the exact versions used for the measurements and are not necessarily the latest available releases.

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, configured completion sources, and folding enabled. The goal was to retain commonly used editor functionality rather than optimize the benchmark configuration solely for insertion speed.

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 is measured through its actual user-facing editing interface. Graphical applications are launched directly from their bundled Mach-O executable to avoid the macOS launch-state latency documented above. Vim and Neovim are tested in Apple Terminal.

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.

The goal is not to force every editor into an identical internal configuration, which is generally not possible. Editors are tested with comparable visible functionality where practical, and benchmark-specific exceptions are documented alongside the affected results.

Features such as fonts, rendering backends, syntax engines, completion, folding, and large-file optimizations differ between editors.

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.

Why are these results different from earlier benchmark versions?

The benchmark methodology was updated to use randomized delays between simulated keypresses rather than a fixed typing interval.

Fixed intervals produced unusually low latency measurements in some editors despite noticeably slower responsiveness during normal typing. Randomizing the delay better represents real typing patterns and exposes work that editors may defer or debounce between keypresses.

Graphical editors are also now launched directly from their bundled Mach-O executables to avoid the macOS launch-state latency documented in Investigating macOS input-to-display latency.

Earlier results should therefore not be compared directly with the current measurements.

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.