Slow startup time for snaps?

snapd
7

I’ve not reviewed the openstack-cli snap, but I know that openstack is written in python with the python files in the read only /snap. If I were going to diagnose this, I would look to see what is happening with the .pyc files since python will try to write them out to to the readonly squashfs and move on, meaning no performance improvements from byte compilation.

I looked into this at one point for python3 and unfortunately, python3 (AFAICT) doesn’t allow you to relocate the __pycache__ directory (someone would have to look into python2, which IIRC openstack still uses). So, for the ufw snap, I hacked around this by creating a dangling symlink in the squashfs from usr/lib/python3/dist-packages/ufw/__pycache__ to /var/snap/ufw/current/usr/lib/python3/dist-packages/ufw/__pycache__, then in a wrapper script for the ufw command I did:

PYCACHE=$SNAP_DATA/usr/lib/python3/dist-packages/ufw/__pycache__
if [ ! -d "$PYCACHE" ] ; then
    mkdir -p "$PYCACHE" 2>/dev/null || true
fi

With the above, it undangles the symlink on first run and the .pyc files are written out to SNAP_DATA such that the second invocation doesn’t have to recompile them.

I did this a long time ago; it would be nice if we didn’t have to jump through such hoops though. Does snapcraft help us with this any now?

2 Likes