Several months ago, we shared an article titled I have a need, a need for snap that detailed the application performance results of snaps compared to their classic repo counterparts. We tested GIMP and VLC on both Ubuntu and Fedora, with some rather interesting findings.

The one aspect of the application usage sequence we did not cover in that piece was the first-time run just after the installation. In general, with graphical software, this used to take a fair deal of time, causing a delay in application opening, and would impair the user experience. We took this problem seriously, and implemented changes that resolve most of the issues, and we’d like to talk about them here.

Overview of the problem

We simulated a typical run of an application after it’s been installed, the same way a Linux user would do. We tested the behavior of the Vscode application,as it’s a fairly representative example of a GUI-based software. After the installation, we timed the loading of Vscode. We conducted several permutations of this test, including different hardware platforms, Linux distributions, and packaging formats (DEB, RPM and Snaps).

The results below were gathered on a system with 6-core/12-thread Xeon(TM) processor, 64GB RAM, 2TB 970 EVO NVMe SSD, and Nvidia Quadro(R) P2000 GPU.

Similarly, we collected the results on a system with 4-core i3(TM) processor, 4GB RAM, 1TB 5,400rpm mechanical hard disk, and Intel(R) HD 440 graphics, on Fedora 29 Workstation and Kubuntu 18.10 distributions.

The significant difference in results between platforms (and on each platform separately) indicates the hardware configuration plays a less important part than the behaviour of the snap sub-system. We focused on profiling the application startup, and after thorough investigation, we narrowed down the issue to font cache generation on the first run.

Namely, graphic desktop applications typically use the fontconfig library to query available fonts on the system. This operation happens on application startup. For improved performance, fontconfig will use font information cache files built by the fc-cache utility available in the fontconfig bundle.

If there are no existing font caches, or they cannot be accessed for any reason, they will be generated. This task can take a long time, especially if there is a large number of fonts that needs to be enumerated (which can vary from system to system, also accounting for some variation in actual application loading times), during which the GUI application may not render on the screen, and users will interpret this delay as a slow application startup.

Fontconfig cache improvements

To resolve the issue of slow application startups due to font cache generation, starting with snap 2.36.2, fc-cache-v6 and fc-cache-v7 binaries are included in the core snap, and they are used to create fontconfig caches automatically when snaps get installed – at the installation time. This operation eliminates the excessively long startup times that some users have been seeing. With these architectural results in place, the results now portray a different picture. While there is still some time penalty, similar to what we have outlined in the first article, the difference is much more tolerable.

On the Xeon(TM)-powered machine, we see roughly a 6x improvement in loading times. For instance, with Ubuntu 18.10, the loading times are reduced from about 2 minutes to about 20 seconds.

On the i3(TM)-powered host, we also see significant improvements. With Fedora 29, the snap startup time is roughly halved. With the Kubuntu 18.10, we have observed a 3x improvement.

In is useful to note that there is also some variation in the startup time of the Vscode application installed from the distribution repo (19.1±5.4 seconds), caused mostly by background system activity. Similarly, on the first test platform, we observed a startup time of 14.5±6.2 seconds for the DEB package.

We also profiled yet a third machine, running 4-core/8-thread i5(TM) processor, 16GM RAM, 500GB SSD, and Intel(R) UHD 620 graphics, with Kubuntu 18.04.2 installed, with the 4.15.0-46-generic kernel and snapd/snapd 2.37.4. On this machine, we observed the most favorable results for both the repo-provided and snap-provided Vscode applications, with very fast launch times (<10 seconds).

With font cache improvements in place, the loading of the Vscode snap takes roughly 4-11 seconds longer than the repo-provided package, with an average value of 6.7 seconds. With the startup times no longer impacted by font caches, we can now also focus on package format and platform-specific differences. From our previous tests, we know that the initial delay of about 2-3 seconds is expected on “cold” application starts. The remaining delta stems from a number of other factors.

For instance, Vscode needs to load its embedded libraries (approximately 80 libraries). This results in about 9,700 I/O operations compared to about ~4,500 I/O operations for the Debian package, which does not use embedded libraries. In general, any approach that bundles libraries has to bear this cost. However, it can be mitigated by sharing libs from a common snap, like the gnome-3-* content snap or via bases.

We will examine and explain these factors in detail in future articles. Indeed, we are continuing to profile and analyze these results, so we can introduce additional optimization and improvements.

Conclusion

The inclusion of fc-cache binaries in snapd 2.36.2 onwards introduces significant (2-6x) improvements in GUI application startup times. The results are applicable for both Ubuntu and non-Ubuntu platforms. Snaps users across different Linux distributions should be able to see immediate, positive differences in the loading of their snaps. The exact figures will depend on the application type, usage patterns and, to a lesser extent, the underlying hardware platform choice.

We believe our testing with Vscode provides a good, indicative example of a complex GUI tool. The reduced application loading times on first run should translate into a more streamlined and enjoyable user experience. If you have any feedback or suggestions on this topic, please join our forum for a discussion.

Photo by Robin Pierre on Unsplash.