Open-sourced your benchmark?

[Naereen]

Hi,

• First, I just tested your project on XUbuntu 16.10, and everything works fine. Good job, it's easy to install and launch.
• I think your warning about the config file in the README.md file might not be necessary (as you say, if the config file is not present, it is created on the first run of alacritty).

I tested alacritty's performance against xfce4-terminal, on simple programs, and on cmatrix. My observation is that runs slightly slower than xfce4-terminal.

But it is unclear how you measured the performance and what kind of benchmarks did you use.
Could it be possible to explain more, and maybe open-source whatever software or script was used for the benchmark?

I would be curious to test again, with a more robust measure.
Thanks.

[elopez]

I'd like to know how performance was measured too. I ran a non-scientific benchmark: executing "time find /usr" a bunch of times on an Arch Linux machine with an SSD. Alacritty took about 40s to print all of it, while GNOME Terminal always finished in under 3s. Even xterm did better, doing it under 6s.

[jwilm]

Benchmarks so far have just involved running find /usr on my Linux system with Alacritty, st, and urxvt, and on macOS against Terminal.app and iTerm2.

maybe it is not a good idea to claim to be fastest (it is a superlative) when you havent tested more than 3 projects.

[MoSal]

Benchmarks so far have just involved running find /usr on my Linux system with Alacritty, st, and urxvt, and on macOS against Terminal.app and iTerm2.

That's hardly an extensive test scenario. And an odd choice of GNU/Linux terminals.

find /usr doesn't cover heavy usage of many codes. Testing with saldl , for example, immediately exposes color issues, flashing every few seconds, among other issues. Those flashes are not seen when using vte-based terminals, konsole, mlterm, or OSX's Terminal. But I do vaguely remember seeing them in ConEmu, and maybe other slow emulators.

While the potential is there, I don't think Alacritty can be called a fast, let alone the fastest, terminal emulator at the moment.

[Naereen]

I agree with @MoSal.

[roobie]

Commands one can use to generate output:

• dd if=/dev/urandom | base64
• cd /; tree

I tested these with Terminator, Sakura and Alacritty, and Alacritty performed very well

EDIT: Dunno if executing inside a tmux session makes a difference, but I tested that as well, which yielded good results.

[jwilm]

I'd like to apologize to those of you who feel mislead about performance claims. You're right that 4 comparisons is not particularly thorough given the volume of terminal emulators on the market. FWIW, I've been doing these comparisons all through development and found Alacritty to be the fastest.

Moving forward, I plan to continue marketing Alacritty as the fastest terminal emulator available and back that up with indisputable benchmarks. It seems like there's a bit of work to do on that front.

while already at it, isnt every terminal emulator "GPU accelerated"? i find it very hard to believe gnome terminal, as an example wouldnt use the graphics card at all. seems kind of strange to make a big deal out of utilizing the graphics card to draw graphics in 2017 - but maybe im wrong?

Assuming for a moment that X drawing APIs use the GPU wherever possible, drawing APIs like that are nearly always done in immediate mode. This mode is incredibly wasteful in the context of a GPU due to frequent uploads, lack of batching, and frequent state changes.

Contrast this with what Alacritty does--retained mode rendering. Display lists for what's on the screen are precomputed from the terminal state. Those lists are uploaded to the GPU, and then everything is drawn at once using only two draw commands.

[Naereen]

Moving forward, I plan to continue marketing Alacritty as the fastest terminal emulator available

It's good to stay positive and motivated about your project, although I really think a serious and complete benchmark is needed (e.g., with plots and tabs of time values, for several heavy commands, as well as CPU/GPU/RAM usage for more than 10 emulators).

One reason for asking for more than find / or cd / ; tree examples is that these examples do not use ANSI color codes, do not use non-ASCII symbols or glyphs.

See for instance the benchmarks displayed on Julia's homepage.

@Naereen actually tree will use LS_COLORS if it's set.

Also don't forget about caches when benchmarking. Consider the following script where alacritty is sure to beat urxvt.

#!/bin/bash
time urxvt -e find /
time alacritty -e find /

A more fair benchmark would be:

#!/bin/bash
time urxvt -e find /
echo 3 > /proc/sys/vm/drop_caches
time alacritty -e find /

[lukaslueg]

We simply need some real #[benchmark]s in alacritty. They can include synthetic tests ("parse 100mb of random stuff", "draw the parsed output of 100mb of random stuff offscreen") and cooked up tests ("here is what the usual output on 12 panes of colored Vim does to you!"). It's the only way to tell if performance increases or decreases over time.

[theduke]

For reference, I'm posting my results here, including a good method of generating random data.

# Generate 100MB of random tex.
cat /dev/urandom | base64 | dd of=/tmp/randomdata bs=1024 count=100KB

# Test. Repeat for each terminal...
# Results are written to bench_XXX.txt
# This also shows MB/s very nicely thanks to `dd`.
{ time dd if=/tmp/randomdata bs=10240; } 2> bench_XXX.txt

My results, on Linux Arch with proprietary Nvidia drivers:

• Terminator: 4.4 MB/s
• urxvt: 19.3 MB/s
• alacritty: 24.5 MB/s

[MoSal]

Here is a more useful test:

while true; do
  sleep 0.01
  echo -e '\r'
  echo -e '\033[0K\033[1mBold\033[0m \033[7mInvert\033[0m \033[4mUnderline\033[0m'
  echo -e '\033[0K\033[1m\033[7m\033[4mBold & Invert & Underline\033[0m'
  echo
  echo -e '\033[0K\033[31m Red \033[32m Green \033[33m Yellow \033[34m Blue \033[35m Magenta \033[36m Cyan \033[0m'
  echo -e '\033[0K\033[1m\033[4m\033[31m Red \033[32m Green \033[33m Yellow \033[34m Blue \033[35m Magenta \033[36m Cyan \033[0m'
  echo
  echo -e '\033[0K\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo -e '\033[0K\033[1m\033[4m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo
  echo -e '\033[0K\033[30m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo -e '\033[0K\033[30m\033[1m\033[4m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo -e '\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A\033[1A'
done

Reduce the sleep interval until the cursor movement becomes obvious. Or remove the sleep, and the last echo, and repeat for X times.

I'd suspect the raw performance will greatly vary depending on the GPU/CPU combination.

For me, the major issue is the flashing/blinking, which I'm seeing every few seconds in alacritty, even with long sleep intervals.

(Off-topic: With zero and positive y offsets. Text seems to be bottom-adjusted instead of centered in each line. Is the default negative to work around this known issue?)

[sijad]

alacritty feel much faster to me:

browsing ~/.config/alacritty/alacritty.yml with vim 8 (default configuration), just keeping up arrow (k) button done.

[quininer]

I have an intuitive way to test terminal performance.
use mpv --vo tct to play a video and see if it is dropped frame.