Some of the more unusual numbers are where I failed to click the close button quickly… 
It looks like it’s marginal and there’s variation, but the ld.so.cache hooks seem to improve startup time by about ~8-10%.
Mmm in this case there is a definite bug with etrace as etrace is supposed to automatically close the window for you so it doesn’t include any human interaction time… thanks for trying it out! I will look into this more and maybe bug you with some details on IRC.
1 Like
Generally speaking yes there is a cost that is due to the compression, but only for certain classes of applications.
I actually did a more thorough review (which led me to develop etrace) on compression and dynamic library loading on snap application startup here and here. Also note that I did measure the effect of no squashfs overhead via snap try, which is detailed in the former post, and there is a small difference between snap try and a squashfs with no compression.
TLDR, for apps that ship a lot of dynamic libraries that the main executable depends on, there will be a more noticable slowdown in the time it takes for them to show a window, primarily because these dynamic libraries all need to be decompressed before the application runs. Apps like games that are very large but do not need to load many large files just to display a window to the user seem to launch quicker because they can decompress all the rest of the files from the snap in the background after the main window has been shown. There is also some slowdown from dynamic library search paths, but this is less significant than the compression effects and requires more snap packaging work to implement a fix for.
1 Like