Significant startup time

[occivink]

Linux, X11. Using eb231b3, release build (the AUR one).

Starting up alacritty takes a significant amount of time. Simply doing time alacritty -e false reports about 390ms. Other terminal emulators, such as urxvt or termite start much faster, at about 160ms for both.
It's also not just a matter of this simple benchmark, in normal usage it also feels slower to start.

[lord-re]

I just tried with an older build and after a git pull and got more or less the same duration ~120ms.
What's your gpu and driver ?

[occivink]

It's an intel HD520, and I don't have the DDX driver installed (so modesetting).
I don't think it's opengl issue, other programs that require opengl contexts (e.g. mpv) are able to start faster.
I'll try to profile the startup time

[alexozer]

I also wish alacritty's startup time was near instant, it's a surprisingly large component of what I look for in my preferred terminal (I would probably switch to alacritty from gnome-terminal if it just started faster). Latency matters.

I tried changing some font / dpi settings and that seemed to affect the startup time too, so who knows which factors cause the most latency. Has a server-client mode for alacritty ever been considered?

[jwilm]

There's some pretty low hanging fruit in this area still before we consider something like a client-server model. For instance, we don't even start the shell (or whatever program) until after the renderer is fully initialized. We have plans (#673) to put the renderer on a secondary thread which will help both startup time and input latency.

[alexozer]

Not really sure what happened but startup performance seems to have, as of now, significantly improved! I'm assuming putting the renderer on a separate thread would still be helpful as a takes a brief bit for the window to draw after the frame opens, but it still seems much faster overall.

[zacps]

I get the following results on a GTX970 with NVIDIA 387.12 drivers and Alacritty @geb231b3:

 Performance counter stats for 'alacritty -e false' (10 runs):
        132.778607      task-clock (msec)         #    0.482 CPUs utilized            ( +-  0.64% )
               187      context-switches          #    0.001 M/sec                    ( +-  5.24% )
                 0      cpu-migrations            #    0.003 K/sec                    ( +- 55.28% )
            20,744      page-faults               #    0.156 M/sec                    ( +-  0.03% )
       472,537,165      cycles                    #    3.559 GHz                      ( +-  0.93% )
       557,793,536      instructions              #    1.18  insn per cycle           ( +-  1.10% )
       115,965,180      branches                  #  873.372 M/sec                    ( +-  1.06% )
         1,361,352      branch-misses             #    1.17% of all branches          ( +-  0.22% )
       141,775,463      L1-dcache-loads           # 1067.758 M/sec                    ( +-  1.39% )
         4,855,266      L1-dcache-load-misses     #    3.42% of all L1-dcache hits    ( +-  0.14% )
         1,337,835      LLC-loads                 #   10.076 M/sec                    ( +-  0.30% )
           601,179      LLC-load-misses           #   44.94% of all LL-cache hits     ( +-  0.53% )
       0.275591435 seconds time elapsed                                          ( +-  2.48% )

Run with sudo perf stat -r 10 -d alacritty -e false

[occivink]

I took a flamegraph out of curiosity, and a surprisingly long time seems spent in libfontconfig and libfreetype.

[torpak]

I just started using the 0.2.0 version because of the scrollback feature.
I noticed that larger history values increase startup time siginficantly:
About a second on my system for 100000 and about 10 seconds for 1000000.
Runtime performance seems unchanged and better than anything else.

[sanga]

I've seen this too. And that's why I dropped the scrollback history to only 1000. Anecdotally (it was quite a while ago when I made that change and I didn't measure it at the time, so take with a grain of salt) that more that halved the startup-time from when scrollback history was at 10,000

[mstoeckl]

With current (release build) master, 80% of callgrind time for alacritty -e false is spent in fontconfig or libc functions called by fontconfig.

For sake of comparison, time alacritty -e false gives 0.890±0.030s real time, while xterm -e false takes 0.216±0.005s; the default st uses 0.193±0.003s, and a heavily patched st hits 0.060±0.005s.

If startup latency is really important to you, a workaround that I've used for some of my programs is to set up a ~50MB bitmap file containing images corresponding to all ~137,000 allocated unicode code points, prerendered in grayscale at my usual font size. Then font loading reduces to calling mmap once and copying memory as needed. The obvious downside is that combining characters, color emoji, oversize characters, and other unicode features are unavailable. (Of course, for some tasks, this "downside" is a feature.)

[chrisduerr]

There has been some further discussion and profiling on this issue in #1603.

I'd be interested to see how Linux and MacOS are different here. So far it seems like most reports are about fontconfig. However if there are caching issues on linux, it's not unlikely they are present on MacOS too.

[jonhoo]

So, specifically the insights from #1603 is that the fontconfig is spent in FcFontMatch, so it's not about rendering specific glyphs as far as I can tell, but about looking up the fonts in the first place. In particular, FcFontMatch is called 14 times during startup, and each call is quite costly, even though I think in theory we should only have to call it a handful of times. Especially if the user is only using a single font. Here's a flamegraph of master that includes the fontconfig symbols as well:

[zacps]

Using some manual tracing (callgraph generator when) I found the following path to FcFontMatch, which I suspect is the problematic one:

* render_cells (for cell in cells)
* GlyphCache::get
* get_glyph
* get_rendered_glyph
* face_for_glyph
* load_face_with_glyph
* FcFontMatch

I'll see if I can eliminate this.

[chrisduerr]

@zacps Thanks for investigating this. Also thanks to @jonhoo for providing so many useful flamegraphs.

It looks like these metrics should allow us to get rid of a significant portion of the startup time. If you need any help, please let me know.

[jwilm]

I'm kind of thinking that I want to try pulling in the font-kit crate rather than investing more time in our own font abstraction. I did some research yesterday on how Pango is doing fallbacks with fontconfig, and I've come to the conclusion that we are pretty far off the mark with our impl.

[zacps]

That sounds like a good idea, do you think it makes sense to start of by writing implementing our current font API for font-kit or adapting the current renderer to font-kit's API?

[kimsnj]

In one of my linux laptops, this is issue is particularly severe: 2s for alacritty -e false vs 140ms for gnome-terminal.

I've tried to generate a flamegraph from master (uploaded along the setup and times) in this gist: https://gist.github.com/kimsnj/6ee1a1992c856fb6a68ee94bee4780d1
(It is however missing some symbols and the rest is mangled).

Update: The issue on my laptop does not seem linked to fonts, but to winit… which takes 2seconds to create the window. I updated the gist with logs that clearly show this.

[jonhoo]

@kimsnj yeah, that's where I ended up too. It's been filed as rust-windowing/winit#682.

[sersorrel]

The startup time for me (measured via time alacritty -e false) significantly increases if I have a compositor running, as well as if I have a second monitor attached:

              | 1 monitor | 2 monitors |
--------------+-----------+------------+
no compositor | 150ms     | 200ms      |
compositor    | 200ms     | 270ms      |

[jonhoo]

@anowlcalledjosh can you give rust-windowing/winit#682 (comment) a try?

[sersorrel]

@jonhoo With that version of winit, the results are much more consistent regardless of the number of monitors! With a compositor, startup takes between 150-200ms; without a compositor, it's pretty consistently about 100ms.

[yaymukund]

Just wanted to attach my benchmarks on wayland, in case it's at all helpful:

# Dell XPS 15" 9560 (just the laptop screen, no external monitors, no touchscreen)
# sway version 1.0-rc1-148-g0df76ed9 (wayland, wlroots)
# alacritty 0.2.9 (`alacritty-git` AUR package, autogenerated alacritty.yml)
$ time alacritty -e bash -c sleep 0
==> alacritty -e bash -c sleep 0  0.10s user 0.04s system 29% cpu 0.475 total

$ time termite -e false
==> termite -e false  0.08s user 0.02s system 101% cpu 0.101 total

# If I disable wayland, it's fast:
$ export WAYLAND_DISPLAY="" ; time alacritty -e false
==> alacritty -e false  0.06s user 0.02s system 82% cpu 0.099 total

Note: I did -e bash -c sleep 0 because -e false would hang indefinitely, for some reason. But ~0.45s seems to match my experience of opening a new alacritty window.

Please let me know if there's anything I can provide that might be helpful. I'm really excited to see alacritty take off 🚀

[kchibisov]

Just aborting the build completely isn't really a fix for that, it just removes support for everyone who might actually try to rely on it.

If they really rely on that they could patch build script, I guess.

[ghost]

My patch is not intended to be a real long-term solution, it's a hack for personal use. I've noticed that issue with the alpha blending but never bothered to fix it because it doesn't affect me. (I only really use a terminal emulator maximized against a solid color background)

[chrisduerr]

If they really rely on that they could patch build script, I guess.

At which point it's not supported anymore though. A bit like stating that Alacritty supports having videos as the background, you just need to write the code to patch it in. That's exactly what not supporting it is.

[kchibisov]

@ddevault your particular issue wrt system's Fontconfig was addressed here 0210a43

[ddevault]

Nice.

[matu3ba]

@ddevault your particular issue wrt system's Fontconfig was addressed here 0210a43

Sorry to be picky, but why is having better speed not a default? How many people do dynamic font loading on their system?

[justyn]

Trying alacritty for the first time on my X1 Carbon 7th Gen, Intel Graphics. Version 0.8.0. Running Ubuntu 20.04 with i3 and compton.

As soon as I add 2 external monitors, alacritty takes a large amount (>1sec) of time to start.

In all these tests of time alacritty -e false the alacritty window is launched on the same internal monitor, all that changes is the number of monitors attached and available.

Internal 4k: 0.212s real
Internal 4k with external 4k: 0.227s real
Internal 4k with external 4k and external FHD: 1.277s real

For some reason the addition of that last FHD monitor seems to cause alacritty to take a full extra second to start up. I don't see this issue at all with gnome-terminal (or anything else, that I can think of).

I note the description of an apparently identical issue with alacrity, but in the winit issue tracker, but that was supposedly fixed 2 years ago.

Any ideas?

[peteromero]

Experiencing slow start on X1 Carbon 8th Gen, running Arch/dwm.
time alacritty -e false gives
0.11s user 0.04s system 19% cpu 0.778 total
Any ideas?

[LukasDoesDev]

Following "benchmarks" on Arch and DWM:

[luukas@superior ~]$ time alacritty -e false

real	0m1.034s
user	0m0.115s
sys	0m0.036s
[luukas@superior ~]$ time st -e false
child exited with status 1

real	0m0.032s
user	0m0.021s
sys	0m0.009s
[luukas@superior ~]$ time urxvt -e false

real	0m0.052s
user	0m0.039s
sys	0m0.008s
[luukas@superior ~]$ time xterm -e false
xterm: cannot load font "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1"

real	0m0.028s
user	0m0.016s
sys	0m0.009s

[LukasDoesDev]

Are there any solutions to this issue?

[chrisduerr]

The issues related to GPU drivers (which seem most of the things mentioned here so far) might be relieved somewhat with #5403. That should skip the driver loading time for new windows from the same instance.

[cagprado]

I’m also affected by the very long startup time when using an external monitor!

My setup:

• Arch Linux, Lenovo X1 Carbon 7th gen
• Intel UHD Graphics 620 (driver: modesetting)
• xorg-server 1.20.13-2 (package)
• fontconfig 2:2.13.94-1 (package)
• alacritty 0.9.0-1 (package)
• glxinfo: OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (WHL GT2)
• laptop screen: 1920x1080+0+1480 (normal left inverted right x axis y axis) 309mm x 174mm
• external monitor: 1440x2560+1920+0 left (normal left inverted right x axis y axis) 597mm x 336mm

This is what I can measure:

time <term> -e false (×5 avg)	alacritty (ms)	zutty (ms)
external HDMI monitor (no)	206.8	73.0
external HDMI monitor (yes)	1134.8	69.4

And my alacritty.conf basically sets up some colors and font:

font:
  size: 13.5
  normal:
    family: Iosevka Term SS17

scrolling:
  history: 2000
  multiplier: 5

colors:
  primary:
    background:     '#fafafa'
    foreground:     '#4d4d4c'
    dim_foreground: '#d6d6d6'
  normal:
    black:          '#4d4d4c'
    red:            '#c82829'
    green:          '#718c00'
    yellow:         '#f5871f'
    blue:           '#4271ae'
    magenta:        '#8959a8'
    cyan:           '#3e999f'
    white:          '#fafafa'
  bright:
    black:          '#4d4d4c'
    red:            '#c82829'
    green:          '#718c00'
    yellow:         '#f5871f'
    blue:           '#4271ae'
    magenta:        '#8959a8'
    cyan:           '#3e999f'
    white:          '#8e908c'
  dim:
    black:          '#d6d6d6'
    red:            '#e19191'
    green:          '#b5c37d'
    yellow:         '#f7c08c'
    blue:           '#9eb5d4'
    magenta:        '#c1a9d1'
    cyan:           '#9cc9cc'
    white:          '#fafafa'
  search:
    matches:
      foreground:   '#efefef'
      background:   '#f5871f'
    focused_match:
      foreground:   '#fafafa'
      background:   '#eab700'
    bar:
      foreground:   '#fafafa'
      background:   '#4d4d4c'

[matu3ba]

@cagprado The external monitor issue sounds related to synchronisation being underspecified in opengl.
context.
However I am not sure, how the Rust bindings to OpenGL exactly work.

200ms sound okayish to me, if all other shells dont support unicode.
@occivink Has the freefont setup issue having multiple calls been fixed?

[krims0n32]

Just chiming in here and wondering if there is any progress on this issue. This seems like the best terminal emulator out there but this startup lag is spoiling the fun a bit :)

○ time st -e false
st -e false  0.02s user 0.01s system 68% cpu 0.048 total
○ time urxvt -e false
urxvt -e false  0.03s user 0.01s system 97% cpu 0.043 total
○ time alacritty -e false
alacritty -e false  0.08s user 0.07s system 61% cpu 0.250 total

Nvidia native driver (Nouveau not supported). Killing compositor kills startup time in half, but I need that to avoid tearing (yes nvidia sucks).

[MahouShoujoMivutilde]

Nvidia native driver (Nouveau not supported). Killing compositor kills startup time in half, but I need that to avoid tearing (yes nvidia sucks).

I use nvidia's proprietary driver too, and you might want to try to disable "allow flipping" like so in nvidia settings.

[krims0n32]

Nvidia native driver (Nouveau not supported). Killing compositor kills startup time in half, but I need that to avoid tearing (yes nvidia sucks).

I use nvidia's proprietary driver too, and you might want to try to disable "allow flipping" like so in nvidia settings.

Thanks, disabling that speeds up Alacritty's startup time a little (50ms) but it causes tearing again in my browser (Brave/Chromium). I've tried different picom backends and settings in the past, but my current configuration is the only one that is workable it seems. My next card probably won't be an Nvidia ..

Now I also just noticed that resizing a tiled (bspwm) alacritty window is super slow so there is more to this it seems. I have zero issues with st, urxvt and others.

If your startup times are significantly better than mine I would love to see your Nvidia/Picom config.

[MahouShoujoMivutilde]

I don't have any tearing with nvidia, even without picom, but I have

this

Section "Screen"
    Identifier     "Screen0"

    # for vsync without compositor
    Option         "metamodes" "nvidia-auto-select +0+0 { ForceCompositionPipeline=On, ForceFullCompositionPipeline = On }"
    Option         "AllowIndirectGLXProtocol" "Off"
    Option         "TripleBuffer" "On"

    # Option         "ConnectToAcpid" "Off"

EndSection

inside /etc/X11/xorg.conf.d/20-nvidia.conf

Added it in few years ago, inspired by wiki.

startup times

~ ❯ hyperfine 'alacritty --class floatme,floatme -e false'
Benchmark 1: alacritty --class floatme,floatme -e false
  Time (mean ± σ):     152.7 ms ±  11.4 ms    [User: 78.0 ms, System: 46.2 ms]
  Range (min … max):   120.5 ms … 168.8 ms    18 runs

100ms better than yours. (gtx 970).

But when nothing aside from alacritty is open, I've seen as low as 115ms. St is still better, tho (~40-50ms).

picom

picom.conf

backend = "glx";

blur: {
    method = "gaussian";
    size = 21;
    deviation = 20.0;
}

blur-background-exclude = [
    "class_g = 'slop'",
    "_GTK_FRAME_EXTENTS@:c"
];

shadow = true;

shadow-exclude-reg = "x27+0-0";

shadow-exclude = [
    "class_g = 'slop'",
    "_GTK_FRAME_EXTENTS@:c"
];


wintypes: {
    tooltip = { fade = true; shadow = true; opacity = 0.9; focus = true; };
    popup_menu = { opacity = 0.9; }
    dropdown_menu = { opacity = 0.9; }
};

Note that I use latest git version and run picom --experimental-backends.

My next card probably won't be an Nvidia

Mine won't be too ;)

Also, while I haven't noticed a significant difference between SyncToVBlank = 1 or 0, I run both nvidia-settings -a "AllowFlipping=0" AND nvidia-settings -a "SyncToVBlank=0". You might want to try it too.

But I think what you're missing is probably triple buffering. Enabling it lowers latency by about 35ms. AllowFlipping=0 lowers by another ~50ms, yes.

resizing a tiled (bspwm) alacritty window is super slow

I think this is general issue with programs that use glx (probably because, as always, nvidia, but idk), regardless of compositor. E.g. mpv has same issues for me (also on bspwm, but used i3, dwm and qtile before that - same), with or without picom.

[chrisduerr]

Closing this issue because there's really nothing left to be done in general as far as the original report is concerned.

Most issues here boil down to slow drivers which is not something Alacritty can fix, but it can be sidestepped with the new multiwindow feature.

Should there be any other issues causing slow-downs that aren't driver related, I encourage people to open separate issues. That way those can actually get fixed.

[braun-steven]

but it can be sidestepped with the new multiwindow feature

Just to make it clear and easier to understand for users that end up here: This feature can be used by calling alacritty msg create-window (needs another running alacritty instance though).

Benchmark for my system with nvidia drivers:

❯ time alacritty -e false
alacritty -e false  0.05s user 0.06s system 29% cpu 0.349 total

❯ time alacritty msg create-window -e false
alacritty msg create-window -e false  0.00s user 0.00s system 93% cpu 0.003 total

This removes any startup delay for me. Thanks, chrisduerr! See Chris' comments below.

[chrisduerr]

This removes any startup delay for me. Thanks, chrisduerr!

This is inaccurate and misleading. It's just not possible to measure the startup delay anymore, that doesn't mean it doesn't exist.

While the startup delay of a new window should be lower than the delay of a new window, it is nowhere near as fast as your "benchmark" suggests. All you're testing is the time it takes to write to the Alacritty socket.

[braun-steven]

Got it, any idea on how to measure the true wallclock time in this case then?

But anyway, using the create-window feature, for me the delay is not noticeable anymore.

[chrisduerr]

Got it, any idea on how to measure the true wallclock time in this case then?

I can't think of any way to do this without modifying the code to include timers. And even then that isn't necessarily directly related to the time things are actually shown on the screen by your compositor.

So the most reliable way? High-speed camera probably.

[restanrm]

This issue is closed but still happening randomly and it is quite painful (note the timestamp in the logs):

$ time alacritty -v -e false
Created log file at "/tmp/Alacritty-2192674.log"
[0.000013535s] [INFO ] [alacritty] Welcome to Alacritty
[0.000102466s] [INFO ] [alacritty] Version 0.10.1 ()
[0.000173448s] [INFO ] [alacritty] Running on Wayland
[0.001241529s] [INFO ] [alacritty] Configuration files loaded from:
                                     "/home/nrm/.config/alacritty/alacritty.yml"
[0.169032035s] [INFO ] [alacritty] Device pixel ratio: 1
[0.175583531s] [INFO ] [alacritty] Initializing glyph cache...
[0.198833350s] [INFO ] [alacritty] ... finished initializing glyph cache in 0.023228021s
[0.198865178s] [INFO ] [alacritty] Cell size: 7 x 17
[0.198873969s] [INFO ] [alacritty] Padding: 0 x 0
[0.198879976s] [INFO ] [alacritty] Width: 800, Height: 600
[0.199616077s] [INFO ] [alacritty] PTY dimensions: 35 x 114
[0.201888388s] [INFO ] [alacritty] Initialisation complete
[0.218863691s] [INFO ] [alacritty] Goodbye
Deleted log file at "/tmp/Alacritty-2192674.log"
alacritty -v -e false  0,13s user 0,05s system 72% cpu 0,251 total
$
$ time alacritty -v -e false
Created log file at "/tmp/Alacritty-2192798.log"
[0.000007084s] [INFO ] [alacritty] Welcome to Alacritty
[0.000066103s] [INFO ] [alacritty] Version 0.10.1 ()
[0.000089791s] [INFO ] [alacritty] Running on Wayland
[0.000615519s] [INFO ] [alacritty] Configuration files loaded from:
                                     "/home/nrm/.config/alacritty/alacritty.yml"
[3.002556990s] [INFO ] [alacritty] Device pixel ratio: 1
[3.009847580s] [INFO ] [alacritty] Initializing glyph cache...
[3.033161227s] [INFO ] [alacritty] ... finished initializing glyph cache in 0.023290061s
[3.033188088s] [INFO ] [alacritty] Cell size: 7 x 17
[3.033196563s] [INFO ] [alacritty] Padding: 0 x 0
[3.033201984s] [INFO ] [alacritty] Width: 800, Height: 600
[3.033987419s] [INFO ] [alacritty] PTY dimensions: 35 x 114
[3.036093887s] [INFO ] [alacritty] Initialisation complete
[3.051778020s] [INFO ] [alacritty] Goodbye
Deleted log file at "/tmp/Alacritty-2192798.log"
alacritty -v -e false  0,09s user 0,06s system 5% cpu 3,074 total

I'm running on Arch, with wayland and alacritty in version 0.10.1 with nvidia-utils installed

[dm17]

Run with sudo perf stat -r 10 -d alacritty -e false

If that can help us debug it, then here's mine (modern Ryzen, newer integrated amdgpu gfx):

 Performance counter stats for 'alacritty -e false' (10 runs):

            560.62 msec task-clock                #    1.059 CPUs utilized            ( +- 18.48% )
              1037      context-switches          #    0.002 M/sec                    ( +-  8.35% )
                35      cpu-migrations            #    0.062 K/sec                    ( +- 10.67% )
             16426      page-faults               #    0.029 M/sec                    ( +-  7.18% )
        1002617172      cycles                    #    1.788 GHz                      ( +- 14.57% )  (75.22%)
         119467299      stalled-cycles-frontend   #   11.92% frontend cycles idle     ( +-  7.51% )  (75.36%)
         156433303      stalled-cycles-backend    #   15.60% backend cycles idle      ( +- 24.55% )  (75.11%)
        1121766552      instructions              #    1.12  insn per cycle
                                                  #    0.14  stalled cycles per insn  ( +- 19.63% )  (75.25%)
         232835996      branches                  #  415.319 M/sec                    ( +- 12.90% )  (75.42%)
           5982434      branch-misses             #    2.57% of all branches          ( +- 14.33% )  (75.27%)
         483486217      L1-dcache-loads           #  862.415 M/sec                    ( +- 23.05% )  (75.12%)
          12271366      L1-dcache-load-misses     #    2.54% of all L1-dcache accesses  ( +- 21.32% )  (74.85%)
   <not supported>      LLC-loads
   <not supported>      LLC-load-misses

             0.529 +- 0.125 seconds time elapsed  ( +- 23.68% )

I see alacritty msg create-window -e false is pretty fast. Now I wonder how I can automatically have that command used for the same keybind after the first window is started in my tiling WM.

[chrisduerr]

@dm17 You can do something like this: alacritty msg create-window || alacritty.

[dm17]

alacritty msg create-window || alacritty

Thanks a lot! Works great... Much more usable, no worries about the first launch. I wonder why this isn't default behavior.

[wthrajat]

For anyone lurking around here like me searching for a solution for i3-wm, you can do it like:

bindsym Mod1 + Return exec --no-startup-id "alacritty msg create-window || alacritty" ; focus

Ofc feel free to customise it according to your configs.

[braun-steven]

The ; focus part shouldn't be necessary. Also, I'm not 100% sure, but I'd avoid adding --no-startup-id since the i3 User's Guide: 6.1. Executing applications (exec) mentions:

With startup-notification, i3 can make sure that a window appears on the workspace on which you used the exec command.

So the correct version would be

bindsym $mod + Return exec alacritty msg create-window || alacritty

where $mod is your modifier of preference.