Hide navigation sidebar
Hide table of contents sidebar
Back to top
Toggle table of contents sidebar

# Performance

The main goals for kitty performance are user perceived latency while typing and “smoothness” while scrolling as well as CPU usage. kitty tries hard to find an optimum balance for these. To that end it keeps a cache of each rendered glyph in video RAM so that font rendering is not a bottleneck. Interaction with child programs takes place in a separate thread from rendering, to improve smoothness. Parsing of the byte stream is done using vector CPU instructions for maximum performance. Updates to the screen typically require sending just a few bytes to the GPU.

There are two config options you can tune to adjust the performance, `repaint_delay` and `input_delay`. These control the artificial delays introduced into the render loop to reduce CPU usage. See Performance tuning for details. See also the `sync_to_monitor` option to further decrease latency at the cost of some screen tearing while scrolling.

## Benchmarks

Measuring terminal emulator performance is fairly subtle, there are three main axes on which performance is measured: Energy usage for typical tasks, Keyboard to screen latency, and throughput (processing large amounts of data).

### Keyboard to screen latency

This is measured either with dedicated hardware, or software such as Typometer. Third party measurements comparing kitty with other terminal emulators on various systems show kitty has best in class keyboard to screen latency.

Note that to minimize latency at the expense of more energy usage, use the following settings in kitty.conf:

    input_delay 0
    repaint_delay 2
    sync_to_monitor no
    wayland_enable_ime no

Hardware based measurement on macOS show that kitty and Apple’s Terminal.app share the crown for best latency. These measurements were done with `input_delay` at its default value of `3 ms` which means kitty’s actual numbers would be even lower.

Typometer based measurements on Linux show that kitty has far and away the best latency of the terminals tested.

### Throughput

kitty has a builtin kitten to measure throughput, it works by dumping large amounts of data of different types into the tty device and measuring how fast the terminal parses and responds to it. The measurements below were taken with the same font, font size and window size for all terminals, and default settings, on the same computer. They clearly show kitty has the fastest throughput. To run the tests yourself, run `kitten __benchmark__` in the terminal emulator you want to test, where the kitten binary is part of the kitty install.

The numbers are megabytes per second of data that the terminal processes. Measurements were taken under Linux/X11 with an `AMD Ryzen 7 PRO 5850U`. Entries are in order of decreasing performance. kitty is twice as fast as the next best.

Terminal | ASCII | Unicode | CSI | Images | Average
--- | --- | --- | --- | --- | ---
kitty 0.33 | 121.8 | 105.0 | 59.8 | 251.6 | 134.55
gnometerm 3.50.1 | 33.4 | 55.0 | 16.1 | 142.8 | 61.83
alacritty 0.13.1 | 43.1 | 46.5 | 32.5 | 94.1 | 54.05
wezterm 20230712 | 16.4 | 26.0 | 11.1 | 140.5 | 48.5
xterm 389 | 47.7 | 18.3 | 0.6 | 56.3 | 30.72
konsole 23.08.04 | 25.2 | 37.7 | 23.6 | 23.4 | 27.48
alacritty+tmux | 30.3 | 7.8 | 14.7 | 46.1 | 24.73

In this table, each column represents different types of data. The CSI column is for data consisting of a mix of typical formatting escape codes and some ASCII only text.

Note

By default, the benchmark kitten suppresses actual rendering, to better focus on parser speed, you can pass it the `--render` flag to not suppress rendering. However, modern terminals typically render asynchronously, therefore the numbers are not really useful for comparison, as it is just a game about how much input to batch before rendering the next frame. However, even with rendering enabled kitty is still faster than all the rest. For brevity those numbers are not included.

Note

foot, iterm2 and Terminal.app are left out as they do not run under X11. Alacritty+tmux is included just to show the effect of putting a terminal multiplexer into the mix (halving throughput) and because alacritty isnt remotely comparable to any of the other terminals feature wise without tmux.

Note

konsole, gnome-terminal and xterm do not support the Synchronized update escape code used to suppress rendering, if and when they gain support for it their numbers are likely to improve by `20 - 50%`, depending on how well they implement it.

### Energy usage

Sadly, I do not have the infrastructure to measure actual energy usage so CPU usage will have to stand in for it. Here are some CPU usage numbers for the task of scrolling a file continuously in less. The CPU usage is for the terminal process and X together and is measured using htop. The measurements are taken at the same font and window size for all terminals on a `Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz` CPU with a `Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X]` GPU.

Terminal | CPU usage (X + terminal)
--- | ---
kitty | 6 - 8%
xterm | 5 - 7% (but scrolling was extremely janky)
termite | 10 - 13%
urxvt | 12 - 14%
gnome-terminal | 15 - 17%
konsole | 29 - 31%

As you can see, kitty uses much less CPU than all terminals, except xterm, but its scrolling “smoothness” is much better than that of xterm (at least to my, admittedly biased, eyes).

## Instrumenting kitty

You can generate detailed per-function performance data using gperftools. Build kitty with `make profile`. Run kitty and perform the task you want to analyse, for example, scrolling a large file with less. After you quit, function call statistics will be displayed in KCachegrind. Hence, profiling is best done on Linux which has these tools easily available.