Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
Found the internet!
r/linuxquestions
r/linuxquestions
10
Posted byu/[deleted]5 months ago

What makes snaps so slow?

On Ubuntu it takes 10 seconds to load firefox whereas it takes a non-snap package a few milliseconds to load. Whats going on behind the scenes?

22 comments
72% Upvoted
level 1

Snaps are stored compressed, and need to be uncompressed before starting. From what I've read, this makes up the bulk of Snap loading times.

20
level 2
[deleted]
· 5 mo. ago

I see. Ill stick with pacman for the time being

5
level 2

Compression is only a significant contributor if the wrong compression algorithm is used. On modern systems LZ4 is near-transparent. Firefox's snap slowness isn't due to compression at the moment. Also it isn't as slow as it used to be, but Canonical folks are still investigating. Snaps aren't universally slow. The Chromium snap for example is fast-fast.

1
level 1

Just to clarify: they're only slow to launch. Once they're running, they're as fast as native, I think.

Since I launch all my major apps once a day at most, and use them all day, I really don't care about an extra 10 seconds at launch.

3
level 1

One of the selling points of snaps for browsers is they are automatically kept up to date, but since I start every login session with sudo apt update && sudo apt upgrade is that even an issue? Does that update all .Deb installs?

2
level 2

Does that update all .Deb installs?

Everything from repo/PPA.

2
level 2

sudo apt update && sudo apt upgrade

Yes, this will update all .deb packages installed in your system that you have repositories for. This will not do a system upgrade, or update your flatpaks.

1
level 2

same with all arch based distros. rolling release means "upgrade all packages every at least day"

1
level 1

Essentially an entire sandboxed virtual operating system is installed and configured within which the application then runs in isolation. Considering that, ten seconds is actually extremely fast.

4
level 1
level 2

This does not answer the question.

13
level 2

Different strokes for different folks

1
level 1

There used to be a font cache issue that caused long loading times, but they fixed it and it's still slow so I don't know. The flatpak is closer to the (loading) speed of the native package but the app itself is slower.

There's a deb package in the PPA from Mozilla.

1
level 1
Comment deleted by user · 5 mo. ago
level 2

The snap daemon is open-source, the snap repo backend is proprietary.

11
level 1

snaps are also mounted.

0
level 1

You could try flatpak Firefox for comparrison....does a similar job.

https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

0
level 1

Hmm.. if only Ubuntu devs knew.. I believe their last take is to get rid of the unneeded language packs hoping that would help (less I/O).

1
level 1

Each snap package is delivered as a compressed SquashFS filesystem that contains all executables, shared libraries, scripts, etc needed by the package. It doesn't get unpacked as a permanent filesystem on disk. Instead, it's mounted as a virtual filesystem, uncompressed as needed. A lot more happens under the hood but that's the main gist of it.
If there are N snap packages, there will be at least N of these virtual mounts. Over time, as the number of snap packages in the system increases, and the burden on the system will become noticeable.
Although snaps can share common libraries (eg. libc, libstdc++) with other snap dependencies, they probably won't be sharing common libraries with the system. This means lots of copies of unshared routines distributed as part of each snap. A system with 16 Gb of RAM, 10th gen (or later) CPU, and M.2 NVMe SSD will probably not be negatively impacted, but ultimately, it will. The reason: because of the constant unpacking of snap virtual mounts and the bloated memory footprint of each package, there will be increasing strain on virtual memory, which means swapping to disk - not the best thing, even for an SSD.
Wait. There's more. Snaps were artificially crafted by Canonical for financial reasons. First, it relieves Canonical of the burden of vetting software on behalf of users. With snaps, the package writer is given that decision. The release coordination to optimize system-wide shared resource usage, package dependencies, etc goes out the window. If a snap package needs a certain version of libc, it simply gets packaged with the snap. With snap release timing left to the package author, snapd can update packages at any time during the day. It's not left to the user to decide this action. Unlike traditional .deb packages where there can be multiple repositories (including non-Ubuntu repos), Ubuntu snaps can only come from the snap store. They can't get updated from anywhere else, because: 1. snapd only looks at the snap store, and 2. snap packages were hard-coded internally to assume the snap store. Somehow it seems that Canonical is trying to emulate the Apple Store, but it's instead coming out with a lemon.
I'm writing this from experience. I have an aging i3 with 16Gb of RAM and a Seagate Barracuda HDD. At first, having Ubuntu with snap packages installed wasn't an issue. Gradually, the impact of snaps made my system run like molasses. I finally got sick of it all, dumped Ubuntu, installed Debian and never looked back. That was 6 months ago. Now the system runs like new. No delays or hangs. Everything runs. Best of all, when I look at system monitor, I see less than 20% memory use, and no swap spillover. The way it should be.

1