If you’re interested in more data, I did a large analysis over here: Squashfs performance effect on snap startup time
Specifically, what it does is this:
- clear the VM caches in the kernel via this code etrace/internal/profiling/profiling.go at master · canonical/etrace · GitHub
- uninstall the snap (which unmounts the squashfs and should in effect free the loopback device)
- reinstall the snap (which should allocate a new loopback device)
- delete all snap user data like profiles (and restore it at the end of the run too so that user’s data isn’t permanently lost)
- discard the snap mount namespace (though again this should be done already by removing the snap)
- start the snap (either with tracing or without, without tracing is the closest to a real run a user would do)
- wait for the snap to display a window and capture the time it took
- immediately kill the snap process and display the output