Would it be possible to eventually add an option to disable all compression when installing all snaps? (Or on a snap to snap basis?)
Would that be a relatively simple change or would it fundamentally break everything?
There seems to be pretty good data out there claiming the reason snaps are often slow to start is due to the compression.
I have Linux on several friends and family members computers, they use maybe 5 - 10% of there mechanical hard-drives and wouldn’t even notice (literally) if snaps where five times bigger once there installed.
I think that is the case with a large number of people. (HDD/SDD space is not a issue.)
The takeaway was that the compression did not play a huge role in cold startup performance once you use LZO. The biggest remaining chunks were related to setting up the confinement (snap-update-ns, mounts etc.).
Thanks for the reply. Even after I’ve rebooted and the recent snaps are all mounted it does seem to take just as long. Seems to backup what your saying.
Pre mounting all those snaps seems to make no difference to how fast they open? It’s done to speed them up I assume?
Snaps are squashfs images, and Squashfs is block-wise compressed. The blocks get uncompressed when they are first accessed and stay in the page cache afterwards (that’s why a warm start is so quick). Mounting the snap does not read all blocks; they will be accessed on the first start.
This part is a little bit faster without compression, that’s true. But not by a huge margin. The part that’s slower than a native program is where snapd, the snap daemon, sets up the execution environment for the process. This cannot be improved by less compression. It would need improvements in snapd or AppArmor etc.
You can’t have the features of snaps without a little cost, that’s just how it is.
I’ve mentioned this before, so I will just leave a TLDR here, but basically we want to have three things with snaps:
We want people that install a snap to get exactly the same bits on their computer (that is the bits that are the .snap file) that the snap publisher uploaded. If snapd dynamically recompresses or uncompresses snaps at runtime, we break this promise and lose some cryptographic guarantees that are important to us.
We want to support snaps on many different OS’s, including really old ones that don’t support new compression settings like zstd, etc.
We want to also support really space limited devices such as IoT devices, so we can’t just pick the default as very large size since this is a bad experience for those users.
