I got some emails from users that my app Sayonara takes very long at first startup. Many users assume that it will take that long at every start and therefore avoid the application. It takes roughly 30 seconds. Starting it the second time takes about 3 seconds. For comparison, the deb version takes about 1 second.
Is there anything I can do?
Here’s the output of snap run --trace-exec sayonara
I think you’re talking about the revision that’s in candidate. That one doesn’t run here:
$ sayonara
/snap/sayonara/196/usr/bin/sayonara: /snap/sayonara/196/kf5/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /snap/sayonara/196/usr/bin/sayonara)
/snap/sayonara/196/usr/bin/sayonara: /snap/sayonara/196/kf5/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /snap/sayonara/196/usr/bin/sayonara)
Your cleanup part looks wrong to me and you’re also referencing outdated content snaps, so I gave it a quick shot:
diff --git a/snap/snapcraft.yaml b/snap/snapcraft.yaml
index ae86f155..c1e836b2 100644
--- a/snap/snapcraft.yaml
+++ b/snap/snapcraft.yaml
@@ -54,9 +54,6 @@ parts:
override-build: |
snapcraftctl build
sed -i 's|Icon=sayonara|Icon=${SNAP}/usr/share/icons/hicolor/256x256/apps/sayonara.png|g' $SNAPCRAFT_PART_INSTALL/usr/share/applications/com.sayonara-player.Sayonara.desktop
- build-snaps:
- - kde-frameworks-5-qt-5-15-3-core20
- - kde-frameworks-5-qt-5-15-3-core20-sdk
build-packages:
- binutils-gold
- clang-10
@@ -106,11 +103,11 @@ parts:
- sayonara
plugin: nil
build-snaps: # List all content-snaps and base snaps you're using here
- - core20
- gtk-common-themes
- - kde-frameworks-5-qt-5-15-3-core20
+ build-environment:
+ - KDE_RUNTIME: kde-frameworks-5-91-qt-5-15-3-core20
override-prime: |
set -eux
- for snap in "core20" "gtk-common-themes" "kde-frameworks-5-qt-5-15-3-core20" ; do # List all content-snaps and base snaps you're using here
+ for snap in "gtk-common-themes" "$KDE_RUNTIME" ; do # List all content-snaps and base snaps you're using here
cd "/snap/$snap/current" && find . -type f,l -exec rm -rf "$SNAPCRAFT_PRIME/{}" \;
done
Cold start: 3.4 s
Warm start: 0.5 s
kde-frameworks-5-91-qt-5-15-3-core20 will soon change to kde-frameworks-5-96-qt-5-15-5-core20 due to an update in snapcraft.
Ah, I can see the problem: I installed stable first, then refreshed to candidate. Because of that, there are now two KDE framework snaps connected to the content plug:
I left them out because (1) the extension already includes them (at least the SDK) in your manifest. You can always check by doing snapcraft expand-extensions, and (2) those snaps are already outdated and not used any more by the extension. The current content snap is kde-frameworks-5-91-qt-5-15-3-core20, and the next one will appear very soon in snapcraft stable.
So the less you hardcode in your manifest, the more will be still relevant when the extension gets an update.
I was just quickly copy & pasting a cleanup part with the correct runtime to check whether that was causing my issues described above. But evidently, it was due to the aforementioned “double connection”.
In any case, your candidate snap looks fine and launches in 3.4 seconds cold on my Dell XPS 13 9370. Your stable is still xz-compressed, so it will surely be a nightmare on desktops.
To sum it up: Compile your snap with LZO, use the correct framework snaps if you reference them, e.g. in your cleanup part, and rebuild the whole snap with a recent snapcraft so that you get around the problem with kde-frameworks-5-plug. Then you should be okay.
I am testing in a VM maybe that’s the reason for the slow startup. It’s still around 30 seconds on first start.
I am building in docker so I cannot use the newest snap. I have to download an older version because with the newest I get an error:
Traceback (most recent call last):
File "/snap/snapcraft/current/bin/snapcraft", line 5, in <module>
from snapcraft.cli import run
ModuleNotFoundError: No module named 'snapcraft'
Maybe. To get better data, try to use the etrace tool (https://snapcraft.io/etrace) on a relevant machine/configuration. For example, there is a huge performance difference between configurations where snapd can mount snaps natively, and where it has to resort to FUSE-based mounting.
I tried to go for KDE’s solution because their Dockerfile looks pretty similar except for the newer snapcraft version.
But there’s a problem that python runs in isolated mode and so, snapcraft_legacy cannot be found [1], although they PYTHONPATH is set in the environment [2]
