Application startup performance

Now Ubuntu 20.04 is out the door there’s a ton more users installing and using some flagship desktop snaps. Startup speed is still being cited as a common complaint when using some of the popuplar snaps such as Chromium, Firefox and LibreOffice.

Some work has been done by @ijohnson to analyse the bottlenecks and has been covered in threads such as Effects of dynamic library caching on Snap startup performance and Squashfs performance effect on snap startup time .

Where are we with these? What wins can we get? What further analysis is needed either in snapd or desktop launchers, fontconfig - or indeed any other part of the stack :D.

@mvo @marcustomlinson @kenvandine @jamesh


you forgot the thread with the awful title (but fruitful content):

1 Like

Regarding some of my investigative work, we will be working on towards this is allowing snaps to use lzo as compression format, but more work on this has fallen to the wayside a bit on my end due to the impending UC20 release (specifically we want to do a thorough check of cross-arch and cross-distro compression of lzo snaps to ensure it’s deterministic). I hope to get back to this work soon, which will unblock snaps from being uploaded to the store using lzo compression.


I’d like to say that I appreciate the open communication and general approach regarding domain-crossing issues shown here and in the “snap universe” in general. This is one of the most engaging, yet competent communities around a complex software I’ve experienced so far.

Makes you really feel like the stakeholders care for the bigger picture and are looking to improve the product and the process all the time.


If you want a snap to test with, GIMP pre-caches the library paths at install/refresh now… it starts pretty quickly for me :wink: Note that I have updated the scripts from Effects of dynamic library caching on Snap startup performance since I copied them from there. They work better cross-platform the way I’ve modified them, so check my new versions at for the latest and greatest!


Another thing publishers can already do is reduce the size of their snap. This has a significant effect on startup time; the DBeaver snap startup went from 6 seconds to 3 seconds, simply by reducing its size. I have had similar success with other snaps such as Foliate and Minecraft Installer.

I took this opportunity to start a page in the docs about reducing the size of desktop snaps. Let me know if you have more tips. Feel free to add them to the page; it should be editable by anyone.


You might want to also add an interface hook so you can update when the gnome-3-28-1804 plug is connected. That’s assuming it fires when the other end is upgraded.


Why not ztsd? It specifically targets fastest possible decompression.

how well does that work on embedded devices (i.e. single core armhf with low ram) … specifically decompressing … note that snaps are used a lot in the IoT and cloud space (where they initially got developed for). It is important that improving snaps on desktops does not degrade performance in these setups …


This is covered specifically in my post, but mainly that zstd is not well supported in older distros we would like to support, bionic for instance does not support zstd compression (last I checked, perhaps the 18.04.4 update now supports it, but it did not originally).

We hope to some day be able to move to zstd for compression, but we want to be sure it is maximally compatible, or barring that we have a fallback mechanism for users who install a snap that their machine can’t decompress they will get an alternative snap file which is just compressed with something they support. That requires even more change than just allowing upload of lzo however.

1 Like