Effects of dynamic library caching on Snap startup performance

I have such a utility that will be the subject of a followup post where I detail how to use it and some different conclusions there.

Yes, this is correct. I didn’t test this, but I assume it would because it the dynamic linker is still searching through directory lists instead of a single place. Additionally, this is uniquely harder than setting up the cache because the cache can be done at runtime with all of the information available, while this has to be done at build time where we may not have all of the information and build scripts may end up guessing somewhat the set of directories that libraries will be in.

This is also true, and it also got me thinking a little bit that another option we have actually is that snapd could setup a proper ld.so.cache “for most things” with expected paths in $SNAP/usr/lib/ and $SNAP/lib/ and $SNAP/usr/lib/x86_64-linux-gnu/, and then snaps could augment those paths with very limited additions to $LD_LIBRARY_PATH if they needed (for example with chromium the directory $SNAP/usr/lib/chromium-browser). My worry here is that snapd would need to be more intelligent about content snaps and things since for example most content snaps will not be in those libraries I mention above (since they can’t just overlay on top of the original snap’s library directories so they are in something like $SNAP/gnome-platform or $SNAP/gnome-runtime). While we could just have snapd look at those too for building the cache now snapd is perhaps getting too intelligent to the point where we run into the issue I mention above where multiple conflicting libraries are put into the cache and it doesn’t “just work”.

Not sure to be honest, maybe someone like @alan_g who is more familiar with the graphics stacks could comment on if those directories are needed/used anymore? Perhaps also comment on the other directories like testability?

Perhaps snapd should grow the ability to introspect the alternatives here, AFAIK it currently only has a static list of libraries/directories that are used. I’d lean towards not changing anything here until someone files a bug about this (perhaps this already exists and my LP searching skills aren’t good enough?)

This is another option, I have updated my proposal to mention this, thanks for bringing this up.

Sure I think this is a great idea and am happy to provide assistance to others as necessary in adapting my scripts here to upstream sources.

1 Like