Snap speed improvements with new compression algorithm!

by Igor Ljubuncic on 27 October 2020

Security and performance are often mutually exclusive concepts. A great user experience is one that manages to blend the two in a way that does not compromise on robust, solid foundations of security on one hand, and a fast, responsive software interaction on the other.

Snaps are self-contained applications, with layered security, and as a result, sometimes, they may have reduced perceived performance compared to those same applications offered via traditional Linux packaging mechanisms. We are well aware of this phenomenon, and we have invested significant effort and time in resolving any speed gaps, while keeping security in mind. Last year, we talked about improved snap startup times following fontconfig cache optimization. Now, we want to tell you about another major milestone – the use of a new compression algorithm for snaps offers 2-3x improvement in application startup times!

LZO and XZ algorithms

By default, snaps are packaged as a compressed, read-only squashfs filesystem using the XZ algorithm. This results in a high level of compression but consequently requires more processing power to uncompress and expand the filesystem for use. On the desktops, users may perceive this as a “slowness” – the time it takes for the application to launch. This is also far more noticeable on first launch only, before the application data is cached in memory. Subsequent launches are fast and typically, there’s little to no difference compared to traditionally packaged applications.

To improve startup times, we decided to test a different algorithm – LZO – which offers lesser compression, but needs less processing power to complete the action. The LZO algorithm was selected because it offers the highest level of compatibility over a number of different use cases.

As a test case, we chose the Chromium browser (stable build, 85.X). We believe this is a highly representative case, for several reasons. One, the browser is a ubiquitous (and popular) application, with frequent usage, so any potential slowness is likely to be noticeable. Two, Chromium is a relatively large and complex application. Three, it is not part of any specific Linux desktop environment, which makes the testing independent and accurate.

For comparison, the XZ-compressed snap weighs ~150 MB, whereas the one using the LZO compression is ~250 MB in size.

Test systems & methodology

We decided to conduct the testing on a range of systems (2015-2020 laptop models), including HDD, SSD and NVMe storage, Intel and Nvidia graphics, as well as several operating systems, including Kubuntu 18.04, Ubuntu 20.04 LTS, Ubuntu 20.10 (pre-release at the time of writing), and Fedora 32 Workstation (just before Fedora 33 release). We believe this offers a good mix of hardware and software, allowing us a broader understanding of our work.

• System 1 with 4-core/8-thread Intel(R) i5(TM) processor, 16GB RAM, 500GB SSD, and Intel(R) UHD 620 graphics, running Kubuntu 18.04.
• System 2 with 4-core Intel(R) i3(TM) processor, 4GB RAM, 1TB 5,400rpm mechanical hard disk, and Intel(R) HD 440 graphics, running Ubuntu 20.04 LTS.
• System 3 with 4-core Intel(R) i3(TM) processor, 4GB RAM, 1TB 5,400rpm mechanical hard disk, and Intel(R) HD 440 graphics, running Fedora 32 Workstation.
• System 4 with 4-core/8-thread Intel(R) i7(TM) processor, 64GB RAM, 1TB NVMe hard disk, and Nvidia GM204M (GeForce GTX 980M), running Ubuntu 20.10.

On each of the selected systems, we examined the time it takes to launch and display the browser window for:

• Native package (DEB or RPM) where available (Kubuntu 18.04 and Fedora 32).
• Snap with XZ compression (all systems).
• Snap with LZO compression (all systems).

We compared the results in the following way:

• Cold start – There is no cached data in the memory.
• Hot start – The browser data is cached in the memory.

Results!

We measured the startup time for the Chromium browser with a new, unused profile. Please note that these results are highly indicative, but there is always a degree of variance in interactive usage measurements, which can result from things like your overall system state, the current system load due to other, background activities, disk usage, your browser profile and add-ons, and other factors.

• The results in the table are average values over multiple runs. The standard deviation is ~0.7 seconds for the cold startups, and ~0.1 seconds for the hot startups.
• The use of the LZO compression offers 40-74% cold startup improvements over the XZ compression.
• On the Kubuntu 18.04 system, which still has Chromium available as a DEB package, the LZO-compressed snap now offers near-identical startup performance!
• On Fedora 32 Workstation, the LZO-compressed snap cold startup is faster than the RPM package by a rather respectable 33% (actual ~5.0 seconds difference).
• Hot startups are largely independent of the packaging format selection.

If you’d like to test for yourself…

You may be interested in profiling the startup time of your browser – or any application for that matter. To that end, we’ve compiled a script, which you can download (link to a GitHub Gist), make the file executable, and run on your system. The script allows you to compare the startup time of any native-packaged software with snaps, and is designed to work with any package manager, so you can use this on Ubuntu, Fedora, openSUSE, Manjaro, etc.

To prevent any potential data loss, the functions are commented out in the main section of the script, so you will need to uncomment them manually before the script does anything.

Summary

We are happy with the improvements that the LZO compression introduces, as it allows users to have a faster, more streamlined experience with their snaps. We can now examine the optimal way to introduce and roll out similar changes with other snaps.

And this is by no means the end of the journey! Far from it. We are working on a whole range of additional improvements and optimizations. When it comes to size, you can use content snaps and stage snaps to reduce the side of your snaps, as well as utilize snapcraft extensions. We’re also working on a fresh set of font cache fixes, and there’s a rather compelling story on this topic, as well, which we will share soon. In the near future, we intend to publish a guide that helps developers trim down their snaps and reduce their overall size, all of which can help create leaner, faster applications.

If you have any comments or suggestions on this topic, we’d like to hear them. You can tell us about your own findings on snap startup performance, and point us to any glaring issues or problems you believe should be addressed, including any specific snaps you think should be profiled and optimized. We are constantly working on improving the user experience, and we take note of any feedback you may have. Meanwhile, enjoy your snappier browsing!

Photo by Ralph Blvmberg on Unsplash.