alacritty: Slow to draw initial window, time spent in FcFontMatch

Which operating system does the issue occur on? Arch Linux If on linux, are you using X11 or Wayland? X11

Here’s a brief screen capture of the issue: https://jon.thesquareplanet.com/share/alacritty-slow-start.mp4

Running it through callgrind, I get a profile that points pretty squarely at FcFontMatch being the culprit. Sadly, bumping the fontconfig and freetype dependencies doesn’t fix the issue (#1602).

callgrind capture

Any suggestions for what to try next? Has anyone else seen a similar issue?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 21 (21 by maintainers)

Most upvoted comments

Yeah, I’ll open a new issue if I discover that the external screen makes a difference.

Digging through, I get these primary call chains (probably incomplete due to inlining):

  • (Display::new + Display::handle_resize + Display::draw) -> FreeTypeRasterizer::get_glyph -> FcFontMatch
  • (Display::new + Display::handle_resize) -> GlyphCache::compute_font_keys -> FreeTypeRasterizer::load_font -> FcFontMatch

If I disable inlining on all GlyphCache methods, I get that the calls are coming from GlyphCache::new, GlyphCache::update_font_size (through Display::new and Display::handle_resize respectively). It looks like there are just many repeated (and unnecessary?) calls to FcFontMatch indirectly through the GlyphCache methods, when in reality those calls could probably all be reduced to a single one. My current profiles suggest that that could possibly be near a 10x speedup for startup.

Filed tomaka/glutin#1070

I’d like to keep discussions on this issue in #782, however this looks like a different problem which is not due to an issue with Alacritty, but a problem with glutin.

I’d recommend to test if this is reproducible with the glutin examples and report it upstream if it is.

Thanks for looking into this. After the big speed improvement with dynamic allocation for large scrollback sizes, further improving Alacritty’s boot time would really be nice.

If you want to take a stab at resolving this issue and have any questions, please let me know.

Okay, I’d then suggest changing the purpose of this issue from solving a bug, to improving startup performance by reducing the FcFontMatch calls. The title seems fine to me, just going to add some tags.

If there’s any actual buggy behavior, it should be tracked in a different issue.

Edit: It would also be interesting to see how this performs on Alacritty, since FcFontMatch should not exist there. If this is glyph-cache related, it might be the same just with a different function call, but it definitely seems to be worth investigating.

Oops, I missed the gif.