Hello Snapcrafters, as we know that the startup speed when launching desktop snap apps for the first time has been improved by recent development happening in snapd, be it utilizing LZO compression for packing snaps or other stuff, here i present you yet another possible solution that can make the launch time even faster:
I think we can make a common directory which will contain everything that is required by desktop snaps like fonts cache, themes cache, icons cache, mime update and other config that every desktop snap create in their home space when they run for the first time. This directory then can be symlinked (or made available to every desktop snap app or even non desktop snaps) inside their home directory space. snapd can keep this directory up to date with the host system when changes occurs in host system. This might require lot of work and design implementations, but if this will be achieved snaps will start faster as they will get these things managed for them by snapd.
Feel free to pass your views on this strategy 
1 Like
If the snaps use the desktop extensions then this should be handled already whenever the snap refreshes (or first installed). The desktop extensions have a hook setup that does the compilation and caching into $SNAP_COMMON
I believe $SNAP_COMMON is specific to a certain Snap; if I got it right, what @keshavnrj proposes is something shared across the system, for all Snaps. I like the idea, but have not a clear view of how difficult it is to implement.
1 Like
Correct, but IIRC the different runtimes require the cache files to be in a format specific for that runtime - e.g. gnome-3-36 needs different caches to gnome-3-38…
1 Like
Yes, and that take time cause newly installed snap have to create its own stuff when it is launched at first time.
I am saying if snapd will be able to manage all these things and the insatlled snaps will just have symlink to the managed common directory that will prevent all of that individual compilation of stuff that usually happen when app starts for first time or after any change in system.
Yes you are right, this could be something the developer have to sort out. Let’s assume somehow we are able to have this kind of mechanism built into snapd or say snapd-desktop extension (we can call it, if turns out to be a thing) all the apps that require gnome-3.38 will start instantly for example.
I was already suspicious that it’d come to this, just wasn’t sure. If this is something tied to the runtime used, then it could be shared among all Snaps using those, or not? For instance, considering current snapcraft extensions,
We could cover many, many Snaps by implementing sharing among those (where applicable, since I believe this change wouldn’t make sense for ROS extensions, for instance).
Please, let me know if I am just talking nonsense, still getting to know nits and grits of this.
@jamesh Can you please provide your input on this, as you have been active in fixing snap theming issues. In particular, how current system of theming fixes the below issue?
There might be some merit here, @ijohnson can confirm, but I believe writable content can now be shared across snaps that use the content interface, we are already moving the bootstrapping logic away from snapcraft and into the relevant content snaps, after that the content snap could expose the generated bits as read-only for all snaps that connect to it.
I am hand waving a bit, but this could mean that common things are generated only once per content using snap and updates to it would be handled by the content snap and not each individual snap.
@kenvandine should we prototype this early next cycle (November)?
1 Like
I guess I should clarify that what would happen here is that updates to the content snap will trigger the respective hooks for the right updates to happen, no changes should be required for snapd (unless we find a bug of course 
).
1 Like
@sergiusens do you mean $SNAP_COMMON from gnome-3-38-2004 is available to the consuming snap?
That’s what I need confirmation of from the snapd team, if that is there, I believe this should work.
So the question here is if the gnome-3-28-2004 snap exposes a content interface slot for $SNAP_COMMON that the other snaps which have a corresponding content interface plug connect to that slot if they can write to that directory ? That should work fine, this is a many-to-1 variant of the content interface which I just made an example for and it worked fine. The snaps themselves would need to handle file locking to prevent snaps starting simultaneously from stepping on each other’s toes if this directory was shared. Also note that this only works to share i.e. $SNAP_COMMON and $SNAP_DATA, not $SNAP_USER_COMMON or $SNAP_USER_DATA so be aware of that but I think all the desktop extensions already handle this as they use the configure hook to run stuff as root and the user level apps still work, etc.
1 Like
I want to move all the bits currently done at the user level to hooks (like the gio schemas or pixbuf cache), my preference would be that the content snap exposes these directories as read only.
It’s great to get confirmation that this works too!
Yes it can be done read-only as well, but note we don’t have any hooks which run as the user unfortunately
Yeah, when I said hooks, I implied system level hooks
So, it is taking shape…
Since it seems content snaps would handle the logic of generating all those caches (turning apps Snaps on consumers), what would trigger a cache update?
