From: Sativa@tella.com   
      
   One hypothesis was centered around the decompression of the   
    squashfs snap taking some time, so we set up tests to run and   
    compare the performance and timing of various supported   
    compression algorithms for squashfs, including: no compression,   
    GZIP, LZO, ZSTD, and of course XZ.   
      
   Another idea was that dynamic library search paths may be slowing   
    things down. While optimizing these does provide some improvement   
    in snap startup times, the contribution was less significant than   
    the change of the compression algorithm. We explored this topic   
    in greater detail in a snapcraft.io forum post.   
      
   Yet another theory was that perhaps snaps were slow due to desktop   
    ?helper scripts?, which are auxiliary shell scripts used to   
    configure applications to ensure compatibility with the graphical   
    system such as X11 or Wayland. Like the dynamic library search   
    paths, the optimization of these scripts did not contribute a   
    significant change or reduction in the overall snap startup   
    times.   
      
   Eventually, we narrowed down our integration on the compression,   
    and found that indeed, using no compression for the squashfs   
    files resulted in the quickest startup time for many different   
    snaps, reducing it by an order of magnitude in some scenarios, on   
    some systems.   
      
   Here is a graph of the various types of compression for the   
    chromium snap specifically.   
      
   The graph above shows the startup time in milliseconds of the   
    chromium snap, with various different compression algorithms   
    used. All times were averaged across multiple runs from a ?cold   
    start? with no caching activated.   
      
   This also demonstrated that in fact the format we initially chose   
    had the worst performance when it comes to this kind of   
    decompression at application startup. At the time when we chose   
    XZ as the format, we were mostly concerned with size and it was   
    expected, if not fully appreciated, that XZ would be slower than   
    other alternatives.   
      
   This investigation made clear that we should evaluate a use of a   
    new compression format, to improve the startup times for snaps   
    geared towards desktop experience rather than size-constrained   
    IoT devices.   
      
   As a middle ground between size and decompression performance, we   
    decided to allow snaps to ?opt-in? to a better performing   
    algorithm. Developers can choose an alternative compression   
    format at build time (before uploading to the store). We decided   
    it would be best not to enable the use of every available   
    compression format, because users on older kernels and distros   
    may not have necessary support for the new algorithm. Thus, if a   
    user tried to install a snap compressed this way, they would not   
    be able to install the application, which creates a poor user   
    story.   
   What we switched to   
      
   Given all our constraints, the bit-for-bit guarantee, the wide   
    cross-distro support and the security-driven consideration   
    (currently) not to re-compress on the fly, we decided to select   
    LZO as the second allowed compression format for snaps. We chose   
    it because it is widely supported by old kernels and systems, it   
    has relatively good performance (much better than XZ and not much   
    worse than ZSTD, for example), and it still provides a good   
    compression ratio, minimizing disk space usage (and network   
    bandwidth).   
      
   Above, you can see a graph of the compression ratio for various   
    representative snaps, where a higher compression ratio is better.   
    We can see that LZO (in purple) has a worse compression ratio   
    than XZ, and in fact is the worst of the 4 formats (except for   
    ?none? which by definition has no compression). However, it still   
    has a ratio of around 2.5-3 for reasonably sized snaps such as   
    chromium and mari0. For very large snaps like supertuxkart, the   
    ratio is very close to 1 for all compression formats and so   
    picking LZO vs XZ is not a big win either way. If you are a snap   
    author and you want to enable your snap to use LZO, have a look   
    at this forum post to see how you can easily make the switch.   
      
   What?s next   
      
   Eventually, we would like to be able to support some sort of   
    dynamic re-compression either on the store side or on the user?s   
    machine, which could potentially allow users with newer kernels   
    to use better compression formats, but still allow users with   
    older kernels to use legacy formats that are supported there.   
    This could also allow users who want to save space but are not as   
    concerned about performance to choose a compression method with a   
    higher compression ratio, or users who want the best performance   
    and for whom space isn?t an issue to choose a more performant   
    algorithm or even no compression.   
   Summary   
      
   User feedback and cross-distro support are both important with   
    snaps. We originally chose xz for various compatibility reasons,   
    but over time we discovered this to be suboptimal for desktop   
    users looking for the best performance comparable with   
    traditional packaging mechanisms. We investigated and selected   
    LZO as an alternative which offers a good balance for many   
    applications between size and speed.   
      
   We hope you found this article interesting and helpful. If you   
    have any ideas or suggestions, please join the discussion at   
    forum.snapcraft.io and let us know your thoughts. We look forward   
    to improving snaps together with your feedback.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)