Can we please take a step back and look at this like any other software in Ubuntu.
We frequently make decisions about what is default in the ISO, or available in the repositories. Often times those software packages aren’t perfect. When there are imperfections, we rely on users and our active community to tell us how the software is not working correctly, so we can fix it. The way we do that, and have done for 15 years now, is via bug reports. Discussion is great, but detailed bug reports are better for letting developers know what’s wrong.
Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.
Here’s a program running as a snap.
$ time snap run wethr
Farnborough, United Kingdom: 15.57C 🌧
Here’s the same program on the same PC running outside of being a snap.
$ time ./wethr.js
Farnborough, United Kingdom: 15.57C 🌧
I ran the same command multiple times and it varies a little each time under both setups. But largely they’re the same, within a few ms. There are other factors at play, such as network latency speaking to a remote server to get the weather, what else is going on, on the PC and the hardware resources. But largely they’re the same.
Desktop applications are way more complicated though. With many libraries and other assets to load, some of the delays get compounded. This is offset by the fact that snaps are compressed on disk, so there’s fewer blocks to read, which is countered by the overhead of the realtime decompression taking some CPU overhead.
Further on top of this is the need to stand up the necessary directories, mounts and caches to ensure the application launches correctly. There is some overhead on doing this on first launch. It was way worse, and was improved recently. It turned out some font caches were being rebuilt on every launch of the application.
So for example on my machine running libreoffice from the deb takes 0.9 seconds to launch, from the snap it takes around 1.8 seconds. That’s certainly a difference, but it’s far from the 15s I have seen quoted here. If people are seeing significant time deltas between deb and snap installations of the same application, please file a bug. By all means link to those bugs here, so we can alert the people responsible and get these issues looked at.
Here’s some suggested places to file bugs:-
To be clear, I’m not trying to shut down discussion of these issues. But just think about what you’re asking for. Snaps have in general significant advantages for developers and users.
- Developers can make one package that runs on many releases of the same distro
- Currently when an update to LibreOffice or Chromium (as examples) is needed, that’s tremendous work for an Ubuntu developer to cover all supported Ubuntu releases - 16.04, 18.04, 18.10, 19.04 and 19.10 (in development)
- With a snsp, they can update one package and benefit users across all those releases
- Snaps automatically update so users have the latest software without manually updating
- Users who prefer manual update can override this to a great degree
- The Snap Store provides delta updates, so users don’t have to download the full snap file every time
- Users get up to date releases
- We have a tremendous number (hundreds of thousands to millions) of users on older releases of Ubuntu. They can get LibreOffice 6.2 where previously they might only have minor point release updates to 5.x
- Developers can push out test releases to users who can test them before they go stable
- Developers can publish one snap which works on multiple distros (less interesting for Ubuntu users)
Sure, they may have shortcomings, and we need to fix those. A rant on a web forum won’t fix those issues though.