A great user experience is (or at least, should be) an integral part of any software that involves user interaction. On the desktop, this starts with the application launch, and continues through the session. The overall time to completion of tasks as well as interactive responsiveness are a core element in this journey.

If you’re a snap developer or publisher, the topic of speed may arise for various reasons. The differences in the overall architecture and principles of operation of snaps, in comparison to software deployed as Deb or RPM packages, can sometimes lead to a slower experience. This goes against the prime directive of desktop usage. In this article, we want to show you a number of methods and tools you can use to make your snaps snappy.

Compression method

As we’ve outlined in the LZO compression adoption announcement last year, the most immediate change that developers can implement is the use of the LZO compression for their snaps. You may also want to check the more detailed follow-up article explaining why this particular compression algorithm was chosen for snaps.

This will result in some increase in the snap size, but it will typically lead to 2-3x improvement in snap startup times. To implement LZO, you need to declare a top-level compression keyword in your snapcraft.yaml file:

compression: lzo

Desktop extensions

Snapcraft extensions are collections of reusable components and declarations that publishers can add to their snapcraft.yaml. These extensions can reduce the size of the snap recipe, as well make snap builds simpler and more consistent. Instead of manually declaring various plugs, build and stage libraries, and environment variables, developers can use an extension, like GNOME or KDE neon, and hide away large chunks of code

...
adopt-info: kblocks
apps:
    kblocks:
        extensions:
        - kde-neon
        common-id: org.kde.kblocks.desktop
...

Snapcraft extensions have other advantages. They reduce the need for in-depth knowledge of the target software stack, offer a common template, and improve security, as they are tested and updated independently.

When it comes to speed, the benefits come in two ways:

• Firstly, Snapcraft extensions can make snap smaller – and thus faster to launch. Among the different magic methods that abstractize code, the extensions declare the use of various content snaps, including runtime libraries, themes, icons, and other assets. Normally, these would have to be decompressed and loaded into memory during the first application runtime (for each snap), which can lead to a time penalty. Any application that relies on common content snaps that have already been loaded into memory will benefit from faster access times. For example, the following definitions are automatically added by the extension:

plugs:
  gnome-3-38-2004:
    default-provider: gnome-3-38-2004
    interface: content
    target: $SNAP/gnome-platform
  gtk-3-themes:
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/themes
  icon-themes:
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/icons
  sound-themes:
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/sounds

• Secondly, the extensions introduce commonality, leading to fewer duplicates or unnecessary content inside snaps. If you manually package snaps, you could add potentially incompatible libraries, duplicates, or unneeded assets, which may complicate the startup sequence and consume more resources. With the extensions, this problem is minimized.

Get your own measurements in…

It is also always useful to try to profile your own snap, to get a good understanding of what it does and how it behaves. You can use a multi-purpose tool like etrace, which is designed to work with snaps, and allows detailed analysis of the startup sequence in a precise way. For instance, the Chromium snap is a great example of a snap that benefited massively from the use of the extensions, both in terms of speed and size.

Other methods

Even if, for some reason, you cannot use the extensions in your workflow, you can adopt some of the ideas and practices embedded in them in your snapcraft.yaml. You can use the content snaps where applicable.

• Remove any unnecessary stage packages.
• Do not include development packages (-dev) in the stage packages section, as these are most likely used in the build step, and not required for runtime.
• Use the prime keyword declaration to exclude any files you do not need in the final artifact (the snap). You can include or exclude files (with the minus (-) sign added). For example, to not add the include and pkgconfig subfolders that may be part of your sources used in the build step of the snap, you could use a declaration like below:

prime:
  - -usr/include
  - -usr/lib/pkgconfig

Summary

The speed and responsiveness of applications contribute greatly to the user experience. With snaps, there could be some differences in typical execution times compared to applications packed the traditional Linux way. However, it is possible to narrow, and even eliminate the gap. The use of the LZO compression and Snapcraft extensions, and the cleanup of unnecessary assets can help make the snaps smaller, tidier and faster to start. If you have any questions or ideas around this topic, please join our forum and let us know what you think.

Photo by Joe Neric on Unsplash.