alacritty: High CPU usage on intensive output

Im using rsync --info=progress2 and this command produces intensive output to show the progress like…

819,739,727,773 48% 214.57MB/s 1:00:43 (xfr#4052060, to-chk=4298036/8350105)

CPU usage during this process around 80% (inside tmux). URxvt/gnome-terminal - are cold displaying the same tmux session.

System

OS: Linux (NixOS) Version: 0.6.0 Linux/BSD: X11/Gnome 3.38.1

Logs


[2020-12-06 20:24:36.475846433] [INFO ] [alacritty] Welcome to Alacritty
Created log file at "/tmp/Alacritty-28665.log"
[2020-12-06 20:24:36.475904034] [INFO ] [alacritty] Configuration files loaded from:
[2020-12-06 20:24:36.475910184] [INFO ] [alacritty]   "/home/taras/.config/alacritty/alacritty.yml"
[2020-12-06 20:24:36.483988330] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Regular, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[2020-12-06 20:24:36.484411843] [DEBUG] [alacritty] Estimated DPR: 1
[2020-12-06 20:24:36.484421393] [DEBUG] [alacritty] Estimated window size: None
[2020-12-06 20:24:36.484424603] [DEBUG] [alacritty] Estimated cell size: 7 x 18
[2020-12-06 20:24:36.619192989] [INFO ] [alacritty] Device pixel ratio: 1
[2020-12-06 20:24:36.622400772] [INFO ] [alacritty] Initializing glyph cache...
[2020-12-06 20:24:36.623795522] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Regular, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[2020-12-06 20:24:36.625333043] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Bold, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[2020-12-06 20:24:36.626907034] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Italic, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[2020-12-06 20:24:36.628531455] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Bold Italic, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[2020-12-06 20:24:36.634027454] [INFO ] [alacritty] ... finished initializing glyph cache in 0.011613362s
[2020-12-06 20:24:36.634058794] [INFO ] [alacritty] Cell size: 7 x 18
[2020-12-06 20:24:36.634065064] [INFO ] [alacritty] Padding: 15 x 15
[2020-12-06 20:24:36.634068274] [INFO ] [alacritty] Width: 800, Height: 600
[2020-12-06 20:24:36.650952433] [INFO ] [alacritty] PTY dimensions: Line(31) x Column(110)
[2020-12-06 20:24:36.654235186] [INFO ] [alacritty] Initialisation complete
[2020-12-06 20:24:36.654555038] [DEBUG] [alacritty_terminal] Term::resize dimensions unchanged
[2020-12-06 20:24:36.654581958] [INFO ] [alacritty] Padding: 15 x 15
[2020-12-06 20:24:36.654587988] [INFO ] [alacritty] Width: 800, Height: 600

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 44 (20 by maintainers)

Most upvoted comments

I don’t see the problem? Are you saying you don’t want Alacritty to use CPU when it has to do a lot of processing, but rather limit its resource usage in favor of slowing down?

If so, I’m not sure why you’re using Alacritty?

If so, I’m not sure why you’re using Alacritty?

is this the way of reacting to the bug report? 😃 I just wanted to let you know that it consumes much higher resources doing the same job compared to other terminals. if it was intended behavior… just close this report then.

PS: the description says “GPU-accelerated terminal emulator”, so why it consumes such an amount of CPU?

There’s nothing to be fixed in Alacritty, since the issue is with the Nvidia drivers.

can’t you please elaborate on your conclusion? not for me, but for the others who experienced the same problem

I’m going back to the gnome-terminal. they finally fixed the annoying bug and now it just works without extra CPU usage.

I wish you guys to change the way you communicating with your users. I believe it’s the worst way to react like “If so, I’m not sure why you’re using Alacritty?” on a bug report and finally you closed the ticket without a solution just blaming Nvidia driver without having any prooves of it.

If you get a hand on nvidia’s proprietary drivers so someone can take a look at them, please do let me know.

Alacritty uses OpenGL, not Vulkan. GALLIUM_HUD is unfortunately not supported by all mesa devices, I’m not entirely sure why or how that works, I just know it works for me.

I guess the excessive cpu usage is specific to nvidia proprietary drivers.

This seems like the most likely explanation, it would be interesting to see if there’s maybe something messed up in the nvidia configuration. This seems like the proprietary nvidia driver might not be blocking on vsync for example. But that’s not really something that should be fixed inside of Alacritty.

Ok, so it seems no one REALLY knows what’s going on and the ticket was closed regardless, telling a majority of linux users that they just have bad luck?

Maybe vsync isn’t working?