The problem is common. When I use snap ‘okular’ because deb version is older, it is so slow to open a pdf, especially the first startup after reboot.
This is still a problem in 18.10. This, and the theming issue, should really be a priority for the snap team, as they are giving people a really bad image of snaps in general. Which is a pity, because I think snaps are a good idea.
To see that this is not an isolated problem, read: “Snap packages are very slow to load in Ubuntu 18.10… why is an incredibly simple app like the default calculator a snap package?”
3 Likes
I had a slow start up problem in GIMP, on “first” snap start up. After that though it flys through the start up. Very (no pun intended) Snappy. Usually on the first launch an app is looking for it’s plug ins and libs it connects to creating a config file, etc… After that though you should be fine.
2 Likes
even if this was the case , you are only saying that snap is part of the problem (it’s causing the delay), but we know it.
Running chromium for the first time on my super-fast desktop (AMD Ryzen 6 cores, 3.6 Ghz) was taking around 20 seconds. I replaced the snap with the deb package and now it takes a fraction of a second.
My personal opinion is that we should not even report this issue here, and ask instead the maintainers of our distributions to not use snap packages, until/unless they work well.
Even the themes not working properly, is not a minor issue on a desktop system. Can you imagine if the applications on Mac/Windows are not looking the same? An application on Windows 10, showing up with a Windows XP theme, would be acceptable? 
This product is not yet mature for the desktop. End of story.
p.s.: this bug was filed on Feb 2018. After 2 years and half we’re here to discuss the same issue!
Nobody denies (or has ever denied) that the added security comes at a cost (the cost of a slower first startup to set up the initial app environment).
most people (millions, snaps allow you to measue that pretty exactly) seem to understand the benefit of having applications executed more securely though and not having a malicious javascript read the passwords for your bitcoin wallet or bank account from disk … and not giving apps the ability to encrypt your data to then blackmail you to pay for unencryption.
The extra security will never come without cost and snaps wont go away … how about helping to improve it and being constructive instead 
note that the original issue of this thread (missing pyc files in python snaps) has also been solved in feb 2018 when the thread was opened. it would have been better you had started a new thread about your concrete problem instead of answering to a nearly three year old openstack problem …
the general first start time has significantly improved since but there will always be a minor overhead, which the majority of users seems to get along with for the benefit of being able to always get the latest version of their sotware, having significantly smaller downloads on updates, the ability to roll back to a former version of the app, taking snapshots of your app data and the possibility of installing multiple versions of the same snap alongside.
most theme issues have been resolved since this thread started, but not all snaps have been re-built by their authors, if you hit a sepcific theme issue, you should contact the snap author …
2 Likes
@ogra What mean “first startup” ? First startup after installation or first startup after each reboot?
For instance:
- I start my Ubuntu 20.10
- I start Bitwarden Desktop, installed with Snap: 10s to start
- I quit Bitwarden and restart it : 1s to start
- I suspend my desktop and restart it
- I start Bitwarden Desktop, installed with Snap: 10s to start
Best regards,
Stéphane
i actually meant first start after install … typically snaps populate ~/snap/<snapname>/current with config files, generate font caches etc etc
if a snap uses lzo compression you will likely not see such a significant difference. though it is indeed normal that the first start takes a bit longer (libs need to be loaded into ram etc) but i wouldnt expect a 1:10 difference, i’d guess bitwarden did not switch to lzo yet (though this is hard to check since they seem to not ship their snapcraft.yaml in the snap and the file command does not give you that info detail for squashfs files)
2 Likes
You can check if a squashfs file uses LZO compression with the -s option to unsquashfs:
$ unsquashfs -s snapd_11512.snap | grep Compression
Compression xz
2 Likes
if a snap uses lzo compression you will likely not see such a significant difference.
You can check if a squashfs file uses LZO compression with the
-soption tounsquashfs:
This is my results:
$ sudo unsquashfs -s /var/lib/snapd/snaps/bitwarden_44.snap | grep "Compression"
Compression xz
$ sudo unsquashfs -s /var/lib/snapd/snaps/spotify_46.snap | grep "Compression"
Compression xz
$ sudo unsquashfs -s /var/lib/snapd/snaps/code_59.snap | grep "Compression"
Compression xz
In this tests, I click on exit directly after bitwarden starting:
After reboot:
$ /usr/bin/snap run --trace-exec bitwarden
Slowest 10 exec calls during snap run:
0.078s snap-update-ns
0.117s /snap/snapd/11402/usr/lib/snapd/snap-confine
0.113s /snap/bitwarden/44/desktop-common.sh
0.023s /usr/bin/dbus-send
0.075s /usr/bin/xdg-settings
0.021s /usr/bin/dbus-send
0.035s /usr/bin/xdg-settings
5.499s /proc/self/exe
7.000s /proc/self/exe
13.644s /snap/bitwarden/44/bitwarden
Total time: 13.931s
Hot start:
$ /usr/bin/snap run --trace-exec bitwarden
Slowest 10 exec calls during snap run:
0.021s /snap/snapd/11402/usr/lib/snapd/snap-confine
0.011s /snap/bitwarden/44/desktop-init.sh
0.110s /snap/bitwarden/44/desktop-common.sh
0.020s /usr/bin/dbus-send
0.038s /usr/bin/xdg-settings
0.015s /usr/bin/dbus-send
0.029s /usr/bin/xdg-settings
3.686s /proc/self/exe
3.770s /proc/self/exe
4.590s /snap/bitwarden/44/bitwarden
Total time: 4.777s
After clear cache:
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ /usr/bin/snap run --trace-exec bitwarden
Slowest 10 exec calls during snap run:
0.130s snap-update-ns
0.149s /snap/snapd/11402/usr/lib/snapd/snap-confine
0.083s /usr/lib/snapd/snap-exec
0.056s /snap/bitwarden/44/command.sh
0.147s /snap/bitwarden/44/desktop-common.sh
0.058s /usr/bin/dbus-send
0.072s /usr/bin/xdg-settings
15.109s /snap/bitwarden/44/bitwarden
5.713s /proc/self/exe
7.716s /proc/self/exe
Total time: 15.690s
Now, I launch bitwarden based on official Debian package:
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time /opt/Bitwarden/bitwarden
/opt/Bitwarden/bitwarden 1,18s user 0,32s system 50% cpu 3,000 total
Some information:
- my CPU: Intel® Core™ i5-4570S CPU @ 2.90GHz
Click to exand
$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz stepping : 3 microcode : 0x28 cpu MHz : 800.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds bogomips : 5796.96 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
Question: why
Some ressources: /proc/sys/vm/drop_caches have an impact on snap application startup and not for Debian application startup?
well, as you have proven above that bitwarden uses xz compression, to populate the caches it needs to decompress the libs and load them to ram so this is expected … might be interesting to re-pack bitwarden with lzo and check the difference …
i know for zoom-client the cold start time with lzo dropped from 15sec to roughly 4 sec and only differs from the deb by roughly 1sec now …
I see that @ijohnson fixed the compression inside the code snap. Have you tried reporting the issue in bitwarden and spotify support channels and asking them to consider using a different compression method?
2 Likes