From 8524e32bd5d560cd20a4e4ab9bbde228f51f9188 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Ekl=C3=B6f?= Date: Tue, 9 Jun 2020 20:58:45 +0200 Subject: [PATCH] doc: benchmark: move alacritty-unicode-random text from footnote to separate chapter --- doc/benchmark.md | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/doc/benchmark.md b/doc/benchmark.md index e92afe17..daac1e10 100644 --- a/doc/benchmark.md +++ b/doc/benchmark.md @@ -81,17 +81,24 @@ Scrollback=10000 lines | scrolling-filled-lines | 1.888s ±0.021 | 2.334s ±0.078 | 2.145s ±0.074 | 3.372s ±0.078 | 2.144s ±0.091 | | unicode-random | 1.545s ±0.229 | 0.164s ±0.012 [^1] | 11.180s ±0.342 | crashed | 11.389s ±0.269 | +[^1]: [Alacritty and "unicode-random"](#alacritty-and-unicode-random) -[^1]: Alacritty is actually **really** slow at rendering this (whether - it is fallback fonts in general, emojis, or something else, I - don't know). I believe the reason it finishes the benchmark so - quickly is because it reads from the PTY in a separate thread, - into a larger receive buffer which is then consumed by the main - thread. This allows the client program to write its output much - faster since it is no longer stalling on a blocked PTY. This means - Alacritty only needs to render a couple of frames since it can - reach the final VT state almost immediately. On the other hand, - `cat`:ing the `unicode-random` test file in an endless loop, or - just manually scrolling up after the benchmark is done is - **slow**, which besides being felt (input lag), can be seen by - setting `debug.render_timer = true` in `alacritty.yml`. + +# Alacritty and "unicode-random" + +Alacritty is actually **really** slow at rendering this (whether it is +fallback fonts in general, emojis, or something else, I don't know). + +I believe the reason it finishes the benchmark so quickly is because +it reads from the PTY in a separate thread, into a larger receive +buffer which is then consumed by the main thread. This allows the +client program to write its output much faster since it is no longer +stalling on a blocked PTY. + +This means Alacritty only needs to render a couple of frames since it +can reach the final VT state almost immediately. + +On the other hand, `cat`:ing the `unicode-random` test file in an +endless loop, or just manually scrolling up after the benchmark is +done is **slow**, which besides being felt (input lag), can be seen by +setting `debug.render_timer = true` in `alacritty.yml`.