Improve performance of icon loading #125

dnkl commented 2022年04月14日 14:57:56 +02:00

• Better follow the XDG spec when looking up icons (https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup). This has resulted in fewer iterations per icon
• Reduce disk I/O by only accessing files when we have a size match, or when we have a potential new "minimim size diff" candidate
• Not trying to open .png files as if there were SVGs, and not trying to open .svg files as if they were PNGs.

First commit adds timing. This means you can get a baseline by checking out that commit.

@WhyNotHugo @tinywrkb I don't expect huge performance gains, but it'd still be interresting to see how much this gives us.

#124

* Better follow the XDG spec when looking up icons (https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup). This has resulted in fewer iterations per icon * Reduce disk I/O by only accessing files when we have a size match, or when we have a potential new "minimim size diff" candidate * Not trying to open `.png` files as if there were SVGs, and not trying to open `.svg` files as if they were PNGs. First commit adds timing. This means you can get a baseline by checking out that commit. @WhyNotHugo @tinywrkb I don't expect _huge_ performance gains, but it'd still be interresting to see how much this gives us. #124

dnkl commented 2022年04月14日 15:01:21 +02:00

My load times have, roughly, been cut in half.

My load times have, roughly, been cut in half.

tinywrkb commented 2022年04月14日 15:54:27 +02:00

nanosvg. Seeing (削除) similar results (削除ここまで) I mean similar performance improvement.
I can't build on Arch Linux with librsvg enabled.
More tests maybe much later toady or next week.

info: wayland.c:1709: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88
info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:639: reloaded icons in 0s 000030121ns
warn: render.c:662: rendered in 0s 000000186ns
warn: render.c:662: rendered in 0s 001597668ns
info: main.c:393: theme: hicolor
warn: icon.c:639: reloaded icons in 0s 214180828ns
warn: render.c:662: rendered in 0s 012087028ns
warn: render.c:662: rendered in 0s 000238247ns
warn: render.c:662: rendered in 0s 005360387ns
warn: render.c:662: rendered in 0s 000747319ns
warn: render.c:662: rendered in 0s 000049674ns
warn: render.c:662: rendered in 0s 003592100ns
warn: render.c:662: rendered in 0s 000137007ns
warn: render.c:662: rendered in 0s 000140508ns
warn: render.c:662: rendered in 0s 058252990ns
warn: render.c:662: rendered in 0s 005438211ns

nanosvg. Seeing ~~similar results~~ I mean similar performance improvement. I can't build on Arch Linux with librsvg enabled. More tests maybe much later toady or next week. ``` info: wayland.c:1709: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88 info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:639: reloaded icons in 0s 000030121ns warn: render.c:662: rendered in 0s 000000186ns warn: render.c:662: rendered in 0s 001597668ns info: main.c:393: theme: hicolor warn: icon.c:639: reloaded icons in 0s 214180828ns warn: render.c:662: rendered in 0s 012087028ns warn: render.c:662: rendered in 0s 000238247ns warn: render.c:662: rendered in 0s 005360387ns warn: render.c:662: rendered in 0s 000747319ns warn: render.c:662: rendered in 0s 000049674ns warn: render.c:662: rendered in 0s 003592100ns warn: render.c:662: rendered in 0s 000137007ns warn: render.c:662: rendered in 0s 000140508ns warn: render.c:662: rendered in 0s 058252990ns warn: render.c:662: rendered in 0s 005438211ns ```

dnkl commented 2022年04月14日 16:47:19 +02:00

I can't build on Arch Linux with librsvg enabled.

Yeah, same here. They've been pretty slow at fixing this one, imho :/

> I can't build on Arch Linux with librsvg enabled. Yeah, same here. They've been pretty slow at fixing this one, imho :/

dnkl commented 2022年04月14日 17:45:32 +02:00

@WhyNotHugo I've pushed a second branch, icon-loading-performance-deferred-load. It's based on this PR, but defers loading/parsing of the svg/png files to render time.

It does seem to improve things further. This PR:

info: main.c:397: theme: candy-icons
warn: icon.c:652: reloaded icons in 0s 014289909ns
warn: render.c:670: rendered in 0s 020755220ns

The new branch:

info: main.c:397: theme: candy-icons
warn: icon.c:673: reloaded icons in 0s 004528195ns
warn: render.c:683: rendered in 0s 024542598ns

As can be seen, icons are now "loaded" (looked up) much faster, but initial frame takes longer to render. Still, it's a net win.

@WhyNotHugo I've pushed a second branch, `icon-loading-performance-deferred-load`. It's based on this PR, but defers loading/parsing of the svg/png files to render time. It does seem to improve things further. This PR: ``` info: main.c:397: theme: candy-icons warn: icon.c:652: reloaded icons in 0s 014289909ns warn: render.c:670: rendered in 0s 020755220ns ``` The new branch: ``` info: main.c:397: theme: candy-icons warn: icon.c:673: reloaded icons in 0s 004528195ns warn: render.c:683: rendered in 0s 024542598ns ``` As can be seen, icons are now "loaded" (looked up) **much** faster, but initial frame takes longer to render. Still, it's a net win.

dnkl commented 2022年04月15日 12:20:12 +02:00

First of all, sorry, I forgot pushing icon-loading-performance-deferred-load yesterday. That's been done now.

I've also done more work on the lookup phase. In short, up until now, the lookup logic has been:

for icon in applications:
 for theme in theme_and_its_parents:
 for icon_dir in theme.icon_dirs:
 for xdg_dir in xdg_config_dirs:
 ...

This means a lot of directory lookups, in total. Realizing that most icons will be in the same directory, I've now changed the logic to:

for theme in theme_and_its_parents:
 for icon_dir in theme.icon_dirs:
 for xdg_dir in xdg_config_dirs:
 for icon in applications:
 ...

I've also pushed a third branch, icon-loading-performance-deferred-load-2. I'm aware this is starting to get confusing, but we currently have:

• master
• icon-loading-performance - this PR. The tip implements the algorithmic changes discussed above.
• icon-loading-performance-deferred-load - this branch, minus this last algorithmic change, plus deferring icon loading/parsing to render time. I'm only keeping this branch to be able to compare benchmark numbers.
• icon-loading-performance-deferred-load-2 - this branch, plus deferring icon loading/parsing to render time.

We've previously talked about loading icons on-demand, and how that can be done. Well, the icon-loading-performance-deferred-load* branches do that. And without introducing a queue system. The downside is that since rendering is done in the main thread, those branches now load the icons in the main thread. I think this is fine. But it could be perceived as sluggish, with a slow-responding UI on slow hardware. Especially if the fuzzel window is displaying many entries at the same time (i.e. a large --lines value).

Thus, yet another improvement would be to keep doing on-demand loading, but offload it to a worker thread. However, before we go there, I'm very interrested in seeing how these last changes are working for both of you, @tinywrkb @WhyNotHugo. Can I ask that you re-run the "benchmarks", on both the HEAD of this branch, and the icon-loading-performance-deferred-load-2?

For reference, here are my numbers:

Branch: master (well, first commit in this branch, with the timing additions, 417add1603)

info: main.c:397: theme: candy-icons
warn: icon.c:573: reloaded icons in 0s 050205811ns
warn: render.c:670: rendered in 0s 049732538ns

Branch: icon-loading-performance (7041cb11ee)

info: main.c:397: theme: candy-icons
warn: icon.c:697: reloaded icons in 0s 016969514ns
warn: render.c:670: rendered in 0s 034049529ns

Branch: icon-loading-performance-deferred-load-2 (0308c47569028c318b7be886a5249f95ad0fab8f)

info: main.c:397: theme: candy-icons
warn: icon.c:718: reloaded icons in 0s 001842693ns
warn: render.c:681: rendered in 0s 037666806ns

And, for completeness:

Branch: icon-loading-performance-deferred-load (37eb13e287a43cea846fba4b3d4fbc981ca1dff2)

info: main.c:397: theme: candy-icons
warn: icon.c:673: reloaded icons in 0s 006681898ns
warn: render.c:683: rendered in 0s 038697848ns

Based on my numbers alone, I'd say lets go with icon-loading-performance-deferred-load-2 (defer loading/parsing icons to render time, and load icons in the main thread).

But, if deferring loading to the main thread is too slow on some systems, then I think we should instead go with this branch as a first step, and then take a look at doing offloaded, on-demand loading instead.

First of all, sorry, I forgot pushing `icon-loading-performance-deferred-load` yesterday. That's been done now. I've also done more work on the lookup phase. In short, up until now, the lookup logic has been: ```python for icon in applications: for theme in theme_and_its_parents: for icon_dir in theme.icon_dirs: for xdg_dir in xdg_config_dirs: ... ``` This means a lot of directory lookups, in total. Realizing that most icons will be in the same directory, I've now changed the logic to: ```python for theme in theme_and_its_parents: for icon_dir in theme.icon_dirs: for xdg_dir in xdg_config_dirs: for icon in applications: ... ``` I've also pushed a **third** branch, `icon-loading-performance-deferred-load-2`. I'm aware this is starting to get confusing, but we currently have: * `master` * `icon-loading-performance` - this PR. The tip implements the algorithmic changes discussed above. * `icon-loading-performance-deferred-load` - this branch, **minus** this last algorithmic change, **plus** deferring icon loading/parsing to render time. I'm only keeping this branch to be able to compare benchmark numbers. * `icon-loading-performance-deferred-load-2` - this branch, **plus** deferring icon loading/parsing to render time. We've previously talked about loading icons on-demand, and how that can be done. Well, the `icon-loading-performance-deferred-load*` branches do that. And without introducing a queue system. The downside is that since rendering is done in the main thread, those branches now **load** the icons in the main thread. I _think_ this is fine. But it _could_ be perceived as sluggish, with a slow-responding UI on slow hardware. Especially if the fuzzel window is displaying many entries at the same time (i.e. a large `--lines` value). Thus, yet another improvement would be to keep doing on-demand loading, but offload it to a worker thread. However, before we go there, I'm very interrested in seeing how these last changes are working for both of you, @tinywrkb @WhyNotHugo. Can I ask that you re-run the "benchmarks", on both the HEAD of this branch, and the `icon-loading-performance-deferred-load-2`? For reference, here are my numbers: Branch: master (well, first commit in this branch, with the timing additions, 417add160305134cd60225ddba649493ba830678) ``` info: main.c:397: theme: candy-icons warn: icon.c:573: reloaded icons in 0s 050205811ns warn: render.c:670: rendered in 0s 049732538ns ``` Branch: icon-loading-performance (7041cb11eeaecdd87e99c82856036d53624ab561) ``` info: main.c:397: theme: candy-icons warn: icon.c:697: reloaded icons in 0s 016969514ns warn: render.c:670: rendered in 0s 034049529ns ``` Branch: icon-loading-performance-deferred-load-2 (0308c47569028c318b7be886a5249f95ad0fab8f) ``` info: main.c:397: theme: candy-icons warn: icon.c:718: reloaded icons in 0s 001842693ns warn: render.c:681: rendered in 0s 037666806ns ``` And, for completeness: Branch: icon-loading-performance-deferred-load (37eb13e287a43cea846fba4b3d4fbc981ca1dff2) ``` info: main.c:397: theme: candy-icons warn: icon.c:673: reloaded icons in 0s 006681898ns warn: render.c:683: rendered in 0s 038697848ns ``` Based on my numbers alone, I'd say lets go with `icon-loading-performance-deferred-load-2` (defer loading/parsing icons to render time, and load icons in the main thread). But, if deferring loading to the main thread is too slow on some systems, then I think we should instead go with this branch as a first step, and then take a look at doing offloaded, on-demand loading instead.

dnkl commented 2022年04月15日 12:24:08 +02:00

But, if deferring loading to the main thread is too slow on some systems, then I think we should instead go with this branch as a first step, and then take a look at doing offloaded, on-demand loading instead.

It should be noted, that if we do this, then I'm also going to try to move SVG rasterization (and PNG resizing) to the worker thread. This is currently being done when rendering, in the main thread (and as mentioned, is the reason the first frame takes so long to render, even on e.g. this branch, where all icons are loaded beforehand, on a separate thread).

> But, if deferring loading to the main thread is too slow on some systems, then I think we should instead go with this branch as a first step, and then take a look at doing offloaded, on-demand loading instead. It should be noted, that if we do this, then I'm also going to try to move SVG rasterization (and PNG resizing) to the worker thread. This is currently being done when rendering, in the main thread (and as mentioned, is the reason the first frame takes so long to render, even on e.g. this branch, where all icons are loaded beforehand, on a separate thread).

dnkl commented 2022年04月15日 13:25:09 +02:00

Oh, and a gentle reminder to do release builds when benchmarking... it's pretty much pointless to benchmark debug builds.

I build with meson --buildtype=release -Db_lto=true ....

Oh, and a gentle reminder to do **release** builds when benchmarking... it's pretty much pointless to benchmark debug builds. I build with `meson --buildtype=release -Db_lto=true ...`.

dogknowsnx commented 2022年04月15日 16:11:17 +02:00

Just a quick feedback, I'm running the icon-loading-performance-deferred-load-2 branch (nanosvg) on a really slow machine, and fuzzel is flying!
Great work - thanks!

Just a quick feedback, I'm running the `icon-loading-performance-deferred-load-2` branch (nanosvg) on a really slow machine, and `fuzzel` is flying! Great work - thanks!

tinywrkb commented 2022年04月16日 17:32:53 +02:00

edit: I forgot to set build type, so need to rebuild and test again.

master

info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88
info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:573: reloaded icons in 0s 000000038ns
warn: render.c:672: rendered in 0s 000000136ns
info: wayland.c:333: cursor theme: (null), size: 24, scale: 1
info: main.c:397: theme: hicolor
warn: icon.c:573: reloaded icons in 0s 905130362ns
warn: render.c:672: rendered in 0s 093903379ns

icon-loading-performance

info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88
info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:697: reloaded icons in 0s 000041694ns
warn: render.c:670: rendered in 0s 000000248ns
warn: render.c:670: rendered in 0s 003008304ns
info: main.c:397: theme: hicolor
warn: png.c:22: libpng: iCCP: known incorrect sRGB profile
warn: icon.c:697: reloaded icons in 0s 222750188ns
warn: render.c:670: rendered in 0s 013901355ns

icon-loading-performance-deferred-load
The margin of error here is too large to conlude anything from the results with this branch.

info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88
info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:673: reloaded icons in 0s 000070490ns
warn: render.c:683: rendered in 0s 000000127ns
info: wayland.c:333: cursor theme: (null), size: 24, scale: 1
info: main.c:397: theme: hicolor
warn: render.c:683: rendered in 0s 002277959ns
warn: icon.c:673: reloaded icons in 0s 210534261ns
warn: render.c:683: rendered in 0s 020908028ns

icon-loading-performance-deferred-load-2
This looks pretty good. I've seen even reloaded icons results lower than 50ms, and margin of error looks to be around 20ms+.

info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88
info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:718: reloaded icons in 0s 000033878ns
warn: render.c:681: rendered in 0s 000000195ns
warn: render.c:681: rendered in 0s 002867767ns
info: main.c:397: theme: hicolor
warn: icon.c:718: reloaded icons in 0s 064188512ns
warn: render.c:681: rendered in 0s 015625286ns

**edit: I forgot to set build type, so need to rebuild and test again.** master ``` info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88 info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:573: reloaded icons in 0s 000000038ns warn: render.c:672: rendered in 0s 000000136ns info: wayland.c:333: cursor theme: (null), size: 24, scale: 1 info: main.c:397: theme: hicolor warn: icon.c:573: reloaded icons in 0s 905130362ns warn: render.c:672: rendered in 0s 093903379ns ``` icon-loading-performance ``` info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88 info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:697: reloaded icons in 0s 000041694ns warn: render.c:670: rendered in 0s 000000248ns warn: render.c:670: rendered in 0s 003008304ns info: main.c:397: theme: hicolor warn: png.c:22: libpng: iCCP: known incorrect sRGB profile warn: icon.c:697: reloaded icons in 0s 222750188ns warn: render.c:670: rendered in 0s 013901355ns ``` icon-loading-performance-deferred-load The margin of error here is too large to conlude anything from the results with this branch. ``` info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88 info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:673: reloaded icons in 0s 000070490ns warn: render.c:683: rendered in 0s 000000127ns info: wayland.c:333: cursor theme: (null), size: 24, scale: 1 info: main.c:397: theme: hicolor warn: render.c:683: rendered in 0s 002277959ns warn: icon.c:673: reloaded icons in 0s 210534261ns warn: render.c:683: rendered in 0s 020908028ns ``` icon-loading-performance-deferred-load-2 This looks pretty good. I've seen even `reloaded icons` results lower than 50ms, and margin of error looks to be around 20ms+. ``` info: wayland.c:1713: HDMI-A-2: 1920x1080+0x0@60Hz DELL U2414H 23.98" scale=1 PPI=96x98 (physical) PPI=96x98 (logical), DPI=91.88 info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/noto/NotoSansMono.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:718: reloaded icons in 0s 000033878ns warn: render.c:681: rendered in 0s 000000195ns warn: render.c:681: rendered in 0s 002867767ns info: main.c:397: theme: hicolor warn: icon.c:718: reloaded icons in 0s 064188512ns warn: render.c:681: rendered in 0s 015625286ns ```

tinywrkb commented 2022年04月16日 18:12:51 +02:00

Now with --buildtype=release -Db_lto=true, and all results are less dispersed.

master

info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:573: reloaded icons in 0s 000000202ns
warn: render.c:672: rendered in 0s 000000145ns
warn: render.c:672: rendered in 0s 002266788ns
info: main.c:397: theme: hicolor
warn: icon.c:573: reloaded icons in 0s 914942279ns

icon-loading-performance

info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:697: reloaded icons in 0s 000032850ns
warn: render.c:670: rendered in 0s 000000116ns
info: wayland.c:333: cursor theme: (null), size: 24, scale: 1
info: main.c:397: theme: hicolor
warn: png.c:22: libpng: iCCP: known incorrect sRGB profile
warn: icon.c:697: reloaded icons in 0s 134730244ns
warn: render.c:670: rendered in 0s 013886430ns

icon-loading-performance-deferred-load

info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:673: reloaded icons in 0s 000027893ns
warn: render.c:683: rendered in 0s 000000178ns
warn: render.c:683: rendered in 0s 001484214ns
info: main.c:397: theme: hicolor
warn: icon.c:673: reloaded icons in 0s 193186898ns
warn: render.c:683: rendered in 0s 015535870ns

icon-loading-performance-deferred-load-2

info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions
info: fcft.c:324: fontconfig: 2.14.0
info: fcft.c:330: freetype: 2.12.0
info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88
warn: icon.c:718: reloaded icons in 0s 000025915ns
warn: render.c:681: rendered in 0s 000000189ns
info: wayland.c:333: cursor theme: (null), size: 24, scale: 1
info: main.c:397: theme: hicolor
warn: icon.c:718: reloaded icons in 0s 046463620ns
warn: render.c:681: rendered in 0s 014683548ns

Now with `--buildtype=release -Db_lto=true`, and all results are less dispersed. master ``` info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:573: reloaded icons in 0s 000000202ns warn: render.c:672: rendered in 0s 000000145ns warn: render.c:672: rendered in 0s 002266788ns info: main.c:397: theme: hicolor warn: icon.c:573: reloaded icons in 0s 914942279ns ``` icon-loading-performance ``` info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:697: reloaded icons in 0s 000032850ns warn: render.c:670: rendered in 0s 000000116ns info: wayland.c:333: cursor theme: (null), size: 24, scale: 1 info: main.c:397: theme: hicolor warn: png.c:22: libpng: iCCP: known incorrect sRGB profile warn: icon.c:697: reloaded icons in 0s 134730244ns warn: render.c:670: rendered in 0s 013886430ns ``` icon-loading-performance-deferred-load ``` info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:673: reloaded icons in 0s 000027893ns warn: render.c:683: rendered in 0s 000000178ns warn: render.c:683: rendered in 0s 001484214ns info: main.c:397: theme: hicolor warn: icon.c:673: reloaded icons in 0s 193186898ns warn: render.c:683: rendered in 0s 015535870ns ``` icon-loading-performance-deferred-load-2 ``` info: fcft.c:314: fcft: 3.0.1 +graphemes +runs -assertions info: fcft.c:324: fontconfig: 2.14.0 info: fcft.c:330: freetype: 2.12.0 info: fcft.c:794: /usr/share/fonts/liberation/LiberationMono-Regular.ttf: size=12.00pt/15px, dpi=91.88 warn: icon.c:718: reloaded icons in 0s 000025915ns warn: render.c:681: rendered in 0s 000000189ns info: wayland.c:333: cursor theme: (null), size: 24, scale: 1 info: main.c:397: theme: hicolor warn: icon.c:718: reloaded icons in 0s 046463620ns warn: render.c:681: rendered in 0s 014683548ns ```

dnkl commented 2022年04月16日 18:15:28 +02:00

@tinywrkb thanks. Looks like yours, and the feedback from @manfred3000 agrees with my results: icon-loading-performance-deferred-load-2 is our next step.

@tinywrkb thanks. Looks like yours, and the feedback from @manfred3000 agrees with my results: `icon-loading-performance-deferred-load-2` is our next step.

dnkl commented 2022年04月18日 18:31:54 +02:00

Closing in favor of #126

Closing in favor of https://codeberg.org/dnkl/fuzzel/pulls/126