30x slower than Terminal.app

[Pyrolistical]

setup:

macOS Sierra 10.12.1
git hash 8d8fca6b039cb8b8b6481658cbb8dc978a580c2f

$ ll pgadmin3-1.22.1.dmg 
-rw-r--r-- 1 rchen staff 14M Feb 29  2016 pgadmin3-1.22.1.dmg
$ sha1sum pgadmin3-1.22.1.dmg
c297d70d88b7bcfa3b281b8ba84065a4e107792d  pgadmin3-1.22.1.dmg

test: time hexdump -C pgadmin3-1.22.1.dmg

alacritty

real    6m1.144s
user    0m15.767s
sys     0m4.075s

Terminal.app

real	0m12.473s
user	0m8.208s
sys	0m1.075s

Alacritty renders at a nice 60 fps, but Terminal.app finishes the hexdump way faster

[jwilm]

Just to be sure, did you compile in release mode? cargo build --release

[Pyrolistical]

Yes I did

[jwilm]

how large is the file you're testing with?

[Pyrolistical]

You can see in the setup, its 14M

[NickeZ]

Did you run it twice to warm up caches?

[Pyrolistical]

ya, i proved its not cached related by:
running it once and ctrl+c around 000d0000, it took around 27 seconds to get there
then I immediately run it again and ctrl+c around 000d0000
it still took 27 seconds. so its already cached

[spiderpug]

I have a 97MB log file that I ran the test with. Once with a fresh application, the again and noted the time taken below:

time cat production.log

Iterm 2, v.3.0.13

• 0,00s user 0,62s system 7% cpu 8,372 total without tmux
• 0,00s user 0,62s system 1% cpu 31,113 total with tmux 1.9a

Terminal.app 2.5.3

• 0,00s user 0,52s system 11% cpu 4,721 total without tmux
• 0,00s user 0,61s system 1% cpu 31,984 total with tmux 1.9a

Alacritty

• 0,00s user 0,51s system 23% cpu 2,157 total without tmux
• 0,00s user 0,55s system 1% cpu 31,410 total with tmux 1.9a

So at least for me it has no speed benefit over any other terminal when using tmux.

[jharlap]

Fresh build of both rust nightly and alacritty yields the following results when hexdumping a 9.8M binary with time hexdump -C my_binary, making sure to cat the same file to /dev/null before each run to ensure hot caches.

# hexdump -C my_binary

iterm2
7.05s user 1.24s system 46% cpu 17.914 total
8.01s user 1.90s system 13% cpu 1:14.49 total (tmux 2.2)

terminal
6.16s user 1.13s system 77% cpu 9.471 total
7.60s user 1.56s system 17% cpu 51.446 total (tmux 2.2)

alacritty
5.19s user 1.01s system 93% cpu 6.647 total
6.64s user 1.41s system 19% cpu 40.290 total (tmux 2.2)

That said, catting a binary seems like a very unusual behaviour, so another test catting a 27M file of source code (time cat big.go):

# cat big.go

iterm2
0.00s user 0.36s system 6% cpu 5.687 total
0.00s user 0.50s system 1% cpu 38.810 total (tmux 2.2)

terminal
0.00s user 0.27s system 9% cpu 2.921 total
0.00s user 0.45s system 1% cpu 29.410 total (tmux 2.2)

alacritty
0.00s user 0.25s system 26% cpu 0.958 total
0.00s user 0.52s system 2% cpu 23.626 total (tmux 2.2)

My two take homes: alacritty is very fast (nice job!), but tmux exacts a punishing performance penalty. Note, that's tmux 2.2 with only set -g default-terminal "screen-256color" in ~/.tmux.conf.

Given the stated intention to not support tabs, let alone more advanced layout, are you also planning on rewriting tmux for performance? ;)

[jwilm]

Given the stated intention to not support tabs, let alone more advanced layout, are you also planning on rewriting tmux for performance? ;)

One of the things happening with notty is the idea of panes. Current vte protocol only supports scrolling regions that span the entire width of the terminal. With panes, you would be able to have scrolling regions for a subset of columns. To help understand, let's consider a vim session having two buffers displayed with a vertical split. With current scroll region technology, scrolling one of these vim windows will cause text for every single visible line to be emitted again from vim. With notty panes, vim could just emit the newest line. For more info, check out #51 and the notty repo.

I'm not interested in writing tmux, but I think it would be interesting to try and add support for panes in a few common applications like vim and tmux. The hard part would be getting the protocol additions widely accepted.

tmux exacts a punishing performance penalty

Folks with tiling window managers are requesting built-in scrolling support because of that. They don't care about tabs (as much), but having to use tmux for scrolling totally defeats the purpose of Alacritty in their case.

Those who require tabs and splits should probably consider other terminal emulators.

[NickeZ]

According to Nicholas Marriott (tmux developer) "panes" already exists in VT420. If VT420 is implemented it would work out of the box with tmux since they already have that implemented.

Should we open an issue about implementing VT420 commands?

[maximbaz]

There were significant performance improvements done in tmux 2.4+, try rerunning your benchmarks on the latest tmux 2.5.

Previously I was totally able to reproduce your numbers on my Linux, but today things are way better:

base64 /dev/urandom | head -c 50000000 > 50mb.txt

cat 50mb.txt  0.00s user 0.51s system 64% cpu 0.787 total  (no tmux)
cat 50mb.txt  0.00s user 0.61s system 34% cpu 1.745 total  (tmux 2.5)

hexdump -C 50mb.txt  11.58s user 3.95s system 99% cpu 15.539 total  (no tmux)
hexdump -C 50mb.txt  10.35s user 3.78s system 99% cpu 14.131 total  (tmux 2.5) !!

[jwilm]

Can't reproduce

Timing for time cat 100mb.file:

• Alacritty => 2.027s
• Terminal => 2.359s
• iTerm2 => Got bored and cancelled after 38s.