KDE snaps performance revving up
by Igor Ljubuncic on 17 March 2022
Speed, or rather, responsiveness is an essential part of the software usage experience. This applies to every technology and domain, snaps included. Indeed, when it comes to snaps, the equation is a bit more complicated and slightly less straightforward because snaps are packaged as compressed, standalone applications and wrapped in a number of security confinement mechanisms, which set them apart from the classical desktop programs. However, the speed and responsiveness imperative remains.
Over the years, the snap development team has put a lot of effort into making snaps more accessible to the users. One of the main venues of focus has been the startup performance of applications. Notably, improvements in the use of the compression algorithm for snaps has led to 30-60% boost in startup times. Developers have started adopting the new LZO algorithm in their workflows, with positive results and feedback from the users. In today’s article, we want to share with you a fresh set of data from the KDE community.
Testing and methodology
To remain consistent in the overall approach, we have used the same tooling and metrics as we did with the Chromium browser experiment 18 months ago, only this time we focused on several KDE applications, built with the XZ and LZO algorithms. Furthermore, the KDE team has also provided us with two versions of their latest KDE Frameworks snap (5.15, built with core20).
To provide a more consistent experience (as well as save valuable disk space), developers who manage multiple applications with a shared DNA can create content snaps that bundle common components used by these different applications in a special type of snaps, which are loaded into memory only once and then accessed and used by these different applications throughout the user’s session.
This means that an initial load of KDE programs into memory will also be affected by the use of the KDE Frameworks snap, which is why it also merits examining the effects of different compression algorithms.
In this first round of testing, we examined the startup times of KBlocks and GCompris, packaged with XZ and LZO algorithms, respectively, and also tested against the KDE Frameworks snap packaged in the same manner.
It is important to note that the results vary from one system to another, actual momentary workload on the system, and that absolute times are less important than the comparative benefits tied to the specific choice of the compression algorithm.
Results
Below is a table listing one of the testing sets, performed on a laptop system with Intel(R) graphics, SSD storage, and the Plasma desktop environment:
| Snap | KBlocks (XZ) Cold/Hot startup (s) | Kblock (LZO)Cold/Hot startup (s) | GCompris (XZ)Cold/Hot startup (s) | GCompris (LZO)Cold/Hot startup (s) |
|---|---|---|---|---|
| KDE Frameworks (XZ) | 6.3/1.1 | 7.9/1.1 | 14.5/1.6 | 9.7/1.1 |
| KDE Frameworks (LZO) | 6.0/1.1 | 3.7/1.1 | 10.5/1.1 | 6.3/1.1 |
The results are quite interesting and largely consistent. The use of the LZO algorithm leads to a significant improvement in overall cold (no caching) startup times (33-40%). The double combination of the LZO algorithm both for the actual snap and the KDE Frameworks leads to the most significant overall improvements (42-67%), in line with the results we observed with Chromium a while back.
As an exception, with KBlocks, the improvement was accomplished primarily by the change in the KDE Frameworks algorithm rather than the snap itself. This warrants further testing and examination. Lastly, hot startup times are mostly identical and unaffected by the choice of the algorithm,
The downside of the use of the LZO algorithm is the size of the snap itself. KBlocks weighs 4 MB compressed with XZ, 6 MB with LZO. GCompris stands at 159 and 194 MB, while the KDE Framework goes from 337 MB to 443 MB as a result of the algorithm change. However, the loss of disk space is proportionately lower than the speed benefits. Furthermore, throughout the history of the snap ecosystem existence, the primary feedback for improvement in graphical desktop application has been around startup times rather than the space usage.
Summary
The initial findings from the first set of newly built KDE snaps utilizing the LZO compression algorithm point favorably to this change. The KDE team will be adopting the measure for their entire set of 100+ snaps available in the Snap Store, rolling the update alongside other changes and fixes in their applications.
If you are interested in testing the improvements yourself, you can try the above snaps from the beta and edge channels, and you can also use and modify the startup time test script from our original Chromium endeavor. Furthermore, if you have any comments or ideas related to the snap performance topic, feel free to join our forum and let us know.
Photo by Zé Ferrari Careto on Unsplash.