Updated on August 13, 2026 by Michael

Code Editor Performance Benchmarks

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, and records the memory required to keep each file open.

Memory usage and usability

Memory values are shown as main process / additional processes / total where an editor uses multiple processes. A dash indicates that the editor did not meet the benchmark requirements.

An editor fails a test if it does not open and become responsive with syntax highlighting working throughout the document within 30 seconds.

• VS Code has degraded performance with the 5M-line file, and is very degraded and practically unusable with the 10M-line file.
• Vim is tested without folding or autocomplete. Performance is degraded with the 1M-line file, and very degraded and practically unusable with the 5M-line file.
• BBEdit has degraded performance with the 1M-line file, and is very degraded and practically unusable with the 5M-line file.
• Lite XL has degraded performance with the 1M-line file, and is very degraded and practically unusable with the 5M-line file.
• Zed spawns clang, which uses approximately 100% CPU with the 1M-line file and 200% CPU with the 5M-line file. Zed itself uses approximately 200% CPU until force quit. Zed fails to open the 10M-line file within the time limit, uses around 16 GB of total memory, then becomes unresponsive during cursor movement and editing.
• TextMate fails to open the 1M-line file with syntax highlighting within the time limit.
• Xcode is very degraded and practically unusable with the 1M-line file, then becomes unresponsive during cursor movement and editing. Memory usage also continues increasing while idle.
• Neovim is tested without folding or autocomplete. Syntax highlighting is enabled but is not applied to the 1M-line file within the time limit.
• Emacs has degraded performance with the 1M-line file, then becomes unresponsive during cursor movement and editing.

Typing latency

P95 latency values for each usable file size.

• BBEdit unable to complete latency test on 5M-lines file.
• Zed unable to complete latency test on 5M-lines file.
• Vim exceeded redraw time on 20M-lines file.

Test environment

Methodology

Each test starts with a fresh editor process. The editor is opened with the test file and allowed up to 30 seconds to finish loading and become responsive with syntax highlighting working throughout the document.

The file is then tested by jumping between the beginning and end, scrolling through different regions, moving the cursor, indenting lines, and inserting new lines. An editor is considered usable at a given file size if it remains responsive throughout this process without requiring force quit or becoming practically unusable due to very high latency.

Memory usage is recorded after this interaction and after the editor has settled. Measurements use the Memory value reported by macOS Activity Monitor. For editors using multiple processes, memory is recorded as main process / additional processes / total.

The editor is completely quit and restarted between each file-size test.

Large-file latency tests are performed only for file sizes where the editor passes the responsiveness requirements above. The same methodology described in Typing latency is used with the larger test files.

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 in the typing-latency benchmarks?

For the typing-latency benchmarks, the goal 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.