Snaps seem to be slower to launch that traditionally packaged applications, why is this and what can be done to make them faster to launch?
Source
Something is being done:
But I don’t really know if something is going on for snaps not based in the gnome-3-26-1604.
2 Likes
I hope the y can fix this, it is true, the snaps are too much slowly to launch
I forgot about that thread so marking this as solved in the hope that people just go to that thread instead, thanks! 
The techniques mentioned in that thread are more broadly applicable, but I haven’t been able to implement them in an automated fashion.
This mainly comes down to the fact that the caches I was looking cover all files found in a directory. While we could make e.g. the desktop-gtk3 part build those caches, that will cause problems if some other part also installs files to those directories. As an example, consider the case of gsettings schemas: GTK provides some if its own, but an app might also have a schema.
That’s not to say there’s nothing to be done at the moment. @oSoMoN added the following to the LibreOffice snap packaging:
This does the following:
- adds a part that runs after everything else that might install to one of these shared directories.
- copy anything that was installed to those directories by other parts from
$SNAPCRAFT_STAGE. - build the caches from the part’s copy of the files.
- stage those files along with the caches.
Unfortunately the ordering primitives don’t make it possible to publish a cloud part that runs after everything else, so you’d need to copy this kind of logic to your own snap to take advantage at the moment.
The longer term solution is for snapcraft to grow some additional scriptlet hooks. The idea then would be to add a scriptlet to desktop-gtk3 that builds the caches in the stage directory after all parts have staged their files. Then things should just work without needing any additional boilerplate like in the LibreOffice snapcraft.yaml.
2 Likes
Snapcraft have added the ability for us to move some application set up from first run to build time. This will significantly improve desktop application first time start up performance, but there is still more we can do. We’ll take a deep dive in to snap start up time and you will see the results of this work apply across all platforms.
Progress is on the way, it seems! 
1 Like
@jamesh is there any more updates on this? Has snapcraft sped up first-run of snaps without additional boilerplate being necessary?
2 Likes