Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alacritty is consistently slower than urxvt in XQuartz (macOS) #205

Open
spaghetti2514 opened this issue Jan 7, 2017 · 35 comments
Open

Alacritty is consistently slower than urxvt in XQuartz (macOS) #205

spaghetti2514 opened this issue Jan 7, 2017 · 35 comments

Comments

@spaghetti2514
Copy link

@spaghetti2514 spaghetti2514 commented Jan 7, 2017

Alacritty’s biggest claim is that it’s the fastest terminal emulator available. If there’s a case where it’s not, then it’s either a bug in Alacritty or a misconfigured system

After a fresh install of Alacritty on OS X, I generated a 38MB text file consisting of 10 million lines of "foo" with the command printf "%0.sfoo\n" {1..10000000} > 10mil.txt and then attempted to compare the speed of Alacritty to the speed of urxvt running in Xquartz by running time cat 10mil.txt a few times in each terminal at a normal size after priming caches.

Times taken in urxvt
2.833s
2.966s
2.555s
Times taken in alacritty
5.611s
5.665s
5.553s

Alacritty’s performance scales well with screen size. Running at larger resolutions will tip the scale further in Alacritty’s favor.

Times taken in urxvt (full screen)
3.348s
3.614s
3.639s
Times taken in alacritty (full screen)
12.819s
12.641s
13.320s

I normally wouldn't consider this a bug, but I figure you probably want all the comparisons you can get if you're trying to make alacritty the fastest terminal emulator. Also thought it was better to open a new issue rather than commenting on an existing performance issue both for organization and because the root causes might be totally different.

Let me know if there's any additional information you'd like me to provide.

Edit:

$ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce 320M OpenGL Engine
OpenGL version string: 2.1 NVIDIA-10.2.12 310.90.10.05b20
OpenGL shading language version string: 1.20
OpenGL extensions:
@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 7, 2017

Are you using Mesa?

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 7, 2017

Thanks for the report, we do want to be aware of all these issues.

@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented Jan 7, 2017

Are you using Mesa?

On OS X? I think Xquartz at least packages some sort of mesa library, but I have no idea if it's being used. And even then, in would only affect urxvt.

Alacritty is just the normal OS X install though. From my understanding of Mesa it shouldn't be involved at all.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 7, 2017

Oh, sorry. I saw urxvt and made an assumption without reading carefully. Yeah, this doesn't sound good. I have a few things in mind that may have a big impact here. I'll follow up soon.

@b52
Copy link

@b52 b52 commented Jan 7, 2017

Similar results when I run the same tests in full screen (5376x3024) on my Dell XPS 13 running Archlinux with the modesetting driver:

urxvt

cat 10mil.txt 0.00s user 3.06s system 98% cpu 3.093 total

alacritty

cat 10mil.txt 0.00s user 22.32s system 22% cpu 1:37.24 total

That's quite a difference in urxvt's favour.

@b52
Copy link

@b52 b52 commented Jan 7, 2017

Another comparison to gnome-terminal with similar findings.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 8, 2017

@b52 are you using the Mesa driver?

@jwilm jwilm added the B - bug label Jan 8, 2017
@manishrjain
Copy link

@manishrjain manishrjain commented Jan 8, 2017

Another comparison with Terminator where Alacritty is slower as well.

@b52
Copy link

@b52 b52 commented Jan 8, 2017

@jwilm Yes:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Iris Graphics 540 (Skylake GT3e) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 13.0.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
@tmalsburg
Copy link

@tmalsburg tmalsburg commented Jan 8, 2017

I tested on Ubuntu 16.10 with time hexdump file.txt in full screen. The size of the file was 65MB. The numbers below are from the second run to warm up the caches:

Alacritty:

real    0m51.136s
user    0m14.060s
sys     0m8.764s

Urxvt:

real	0m17.579s
user	0m10.396s
sys	0m6.604s
$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 11.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
@nykma
Copy link

@nykma nykma commented Jan 12, 2017

Here goes my time cat 10mil.txt results, tested in ArchLinux on MacBookPro 12,1, Dell U2412M(1920*1200), i3wm, xft:mononoki:size=8, all fullscreen:

urxvt:

real	0m3.063s
user	0m0.000s
sys	0m2.963s

alacritty:

real    1m38.291s
user    0m0.003s
sys     0m4.930s

BTW, how can I check which graphic driver I'm using? I've installed xf86-video-intel, wanna check if this is activated or not.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 12, 2017

@nykma glxinfo | grep OpenGL

@Senjai
Copy link

@Senjai Senjai commented Jan 12, 2017

I'm just going to chime in here and say on Ubuntu gnome I get marked increases in speed when using Nvidia drivers from edgers. Gnome terminal is a no contest and I get about a second difference compared to uxvrt

@Senjai
Copy link

@Senjai Senjai commented Jan 12, 2017

@b52 try out the proprietary drivers

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Jan 12, 2017

I am hoping to fix the Mesa issue so this part of the perf problem will go away. Although perf can currently be improved by installing the proprietary driver, I don't think it's the project's place to be encouraging that.

@nykma
Copy link

@nykma nykma commented Jan 12, 2017

@jwilm Thanks.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Iris 6100 (Broadwell GT3) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
@Senjai
Copy link

@Senjai Senjai commented Jan 16, 2017

As a follow up here, with:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 650 Ti BOOST/PCIe/SSE2
OpenGL core profile version string: 4.4.0 NVIDIA 340.76
OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.4.0 NVIDIA 340.76
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 NVIDIA 340.76 340.76
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

I get find /usr 0.24s user 0.88s system 54% cpu 2.080 total on Alacritty,
and find /usr 0.30s user 0.87s system 55% cpu 2.092 total on Urxvt.

Both with warm FS caches.

@b52
Copy link

@b52 b52 commented Apr 28, 2017

I was wondering what the progress on this one is.

I think the claim made in the README is kinda bold, given that there are serious performance issues compared to other terminals on some standard platforms.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Apr 28, 2017

Hey @b52,

This issue has actually been resolved. There were several duplicates open at one point, and I must have missed this one after the patch.

Did you experience an issue yourself?

@jwilm jwilm closed this Apr 28, 2017
@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented Apr 28, 2017

@jwilm,
This hasn't been fixed and shouldn't be closed. I just rebuilt alacritty from head and tried the benchmark as outlined in the original issue, and alacritty is the same speed as before (much slower than urxvt and getting worse with larger screen size).

I know there have been some people who commented on this issue who were actually having mesa issues, but the original issue has nothing to do with that.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented Apr 28, 2017

@spaghetti2514 oops, my mistake! I looked up at @b52's last comment and it showed the Mesa driver. Going to update the title so I don't make this mistake again.

@jwilm jwilm reopened this Apr 28, 2017
@jwilm jwilm changed the title Alacritty is consistently slower than urxvt Alacritty is consistently slower than urxvt in XQuartz (macOS) Apr 28, 2017
@b52
Copy link

@b52 b52 commented May 2, 2017

@jwilm I also rebuilt the latest HEAD and still have the same performance issues as outlined in this issue.

@jwilm
Copy link
Collaborator

@jwilm jwilm commented May 2, 2017

@b52 the Mesa driver issue should be resolved. If that's not the case for you, could you please open a separate issue with current perf details?

@Senjai
Copy link

@Senjai Senjai commented May 2, 2017

@jwilm what ref was that fixed in? I'm just curious is all to see sht the issue was

@jwilm
Copy link
Collaborator

@jwilm jwilm commented May 2, 2017

@chrisduerr
Copy link
Collaborator

@chrisduerr chrisduerr commented May 18, 2018

I'd be curious how this benchmark performs on the scrollback PR. It should be faster than urxvt/st now. At least it has been on my machine.

@spaghetti2514 if you're still around I'd love to hear your feedback on that!

@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented May 19, 2018

@chrisduerr Performance of the scrollback branch is significantly worse for me.

For the same time cat 10mil.txt with primed caches

urxvt
2.824s
2.826s
2.984s

alacritty
10.714s
10.354s
10.483s

alacritty (fullscreen)
20.166s
20.745s
20.518s

Using master, the times taken are more in line with the numbers from my original comment, so this is caused by something in the scrollback branch specifically.

@chrisduerr
Copy link
Collaborator

@chrisduerr chrisduerr commented May 19, 2018

@spaghetti2514 Are those numbers inside of tmux? That makes a big difference.

@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented May 19, 2018

@chrisduerr No. Should they be?

Edit: Just tested it and alacritty takes 18s (25s fullscreened) for the same benchmark inside tmux.

@chrisduerr
Copy link
Collaborator

@chrisduerr chrisduerr commented May 19, 2018

No they should not be. But that definitely sounds like there's something odd going on. Did you compile the scrollback branch with the --release flag?

@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented May 19, 2018

Yes. Updated to the latest stable rustc, git pull'd, checked out scrollback, cargo build --release

@chrisduerr
Copy link
Collaborator

@chrisduerr chrisduerr commented May 19, 2018

Hmm, for now I'd wait until #1316 gets fixed, even though that shouldn't be the issue, but it might still help. After that it might make sense to look at this issue again.

@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented May 19, 2018

Alright. Ping me again when it's fixed and I'll recompile and try again.

@chrisduerr
Copy link
Collaborator

@chrisduerr chrisduerr commented Sep 28, 2018

There has been some in-depth testing for the Scrollback release an my Mesa system and it outperformed URxvt in every benchmark.

The #1316 issue has significantly improved some aspects of it, so re-testing the current master probably makes sense.

@spaghetti2514 if you're still around and want to benchmark it again, please let me know what your results are.

Otherwise this issue can probably be closed since performance when scrolling should now be pretty much identical to URxvt on the latest master.

@chrisduerr chrisduerr closed this Sep 28, 2018
@chrisduerr chrisduerr reopened this Sep 28, 2018
@chrisduerr chrisduerr closed this Nov 14, 2018
@spaghetti2514
Copy link
Author

@spaghetti2514 spaghetti2514 commented Nov 15, 2018

@chrisduerr It's gotten somewhat faster, especially at larger window sizes, but it's still not as fast as urxvt.
Compiled alacritty from master using the latest rustc nightly with cargo build --release

urxvt: 2.8s
alacritty: 4.4s

urxvt (full screen): 3.1s
alacritty (full screen): 5.9s

The above are all averages of a few runs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.