9

Straight from cold Fossa boot, until usable user interface:

Blender 2.91.2: 4 seconds

Gimp: 11 seconds

Boxy SVG: 22 seconds

Spotify: 43 seconds

The latter two seem like electron apps and take forever. Since these electron apps seem to be increasingly common, is there a way to speed up their snap load times? Spotify in particular is egregious.

2
  • An alternative to snap that doesn't suffer from the slow startup is Flatpak. flathub.org/home – rtclark Feb 23 at 16:50
  • Spotify is not an Electron app and Boxy SVG is – Ray Wu Feb 23 at 17:27
8

This is not a direct answer as it isn't a way to speed up snaps, but it may help anyway.

Spotify is available as a .deb which you can install in Ubuntu instead of using the snap.

I tested both options on my system and got the following approximate results:

Snap -> 7.5 seconds

Apt -> 0.5 seconds

Which raises another point. You mentioned in a comment that you're running on a 2.5gb/s NVME SSD which suggests to me you have a fairly modern PC. I'm running something similar but I can load Spotify as a snap in 7.5 seconds compared to your 43 seconds. Perhaps you have some other issue on your system. 43 seconds does seem excessively slow on a modern PC, even for a snap.

1
  • I'm running ZFS on root partition which might not be in a happy marriage with Snap. Dunno. – Thomas Browne Feb 23 at 22:09
6

You are correct: Some toolkits offer high compatibility, but at a price in performance.

As a user, there is nothing you can do about it at runtime. Snapd does not have a secret Turbo setting, sorry.

File a bug or issue with the snap author.

Skilled users can help: Historically, packaging has been a community volunteer role, not a developer chore. Developers sometimes choose electron and other toolkits when they want to distribute, but lack enough community members to help them package for multiple platforms. In other words, if you get involved, you can make a difference. You can make it better.

6
  • 2
    I'm slightly confused what you're suggesting in your last paragraph. Are you saying that an Electron app can be converted into a non-Electron app just by re-packaging it? Or just that the Snap for an Electron app can be optimised not to include unused parts of the Electron platform? – IMSoP Feb 23 at 9:19
  • @IMSoP I'm confused too, but I suspect it should read "natively instead of using snap" rather than "natively instead of using electron". – Jon Bentley Feb 23 at 9:21
  • Edited to reduce confusion: It's going to be different for each project. – user535733 Feb 23 at 9:52
  • 5
    @user535733 That doesn't really clarify for me. Rewriting an Electron app to use some other technology would be a major undertaking, with a huge impact on the entire project, not something that an outsider to the project could just offer out of the blue. Also note that 3 out of the 4 applications mentioned are proprietary, so there isn't even a community to help. Unless, that is, you really are just talking about how the Snap package is put together, but then you're kind of begging the question: what is it about these Snaps that makes them slow, and how could one offer to speed them up? – IMSoP Feb 23 at 10:40
  • 3
    @user535733 I'm sorry, I still fundamentally disagree that that's useful advice. Something as fundamental as using Electron is always a key design decision for a project, which is very hard to change once it's been made. It might be a bad decision, but the "influence" that you're suggesting is to propose a complete rewrite of the application. Using a platform like Electron has absolutely nothing to do with "packaging", it's at the very foundation of the application; you might as well say that writing your code in PHP rather than Rust is a "packaging decision". – IMSoP Feb 23 at 15:58
3

Snap packagers need to opt in to include lzo compression so that it's not using the slower xz compression when they're installed on your system:

Spotify is one of the worst cases of this and they probably should turn it on. In certain cases, like Chromium, the difference was significant and now it launches fast once that change was committed by the packagers.

2

I think the most simple answer is a bigger package will take more time to start than smaller ones, Spotify is based on electron which (I think) is essentially translating a web app into a package/app which is convenient for companies because they don't need to hire more developers to work on another version of the software but the other hand, it's taking too many resources, we can only hope that developers and companies make more effort into making their apps (especially paid ones), I'd recommend on upgrading to an SSD for better performance system-wide.

New contributor
saadiens is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
3
  • 2
    thanks yes makes sense, but this is already running of a 2.5G per second NVME SSD. Also Electron apps via apt are at least 3x faster. Still slow but much faster than snap. – Thomas Browne Feb 22 at 22:06
  • "convenient for companies because they don't need to hire more developers to work on another version of the software" - makese sense for small to medium sized companies, but doesn't make much sense for e.g. Spotify which is currently worth $66bn. A few extra developers is pocket change. On the other hand, it's hard to think of another plausible reason. – Jon Bentley Feb 23 at 9:26
  • 1
    @JonBentley Yeah, the emphasis is somewhat off on that sentence. Electron is a platform for building applications, and developers use it for the same reason they use any other library or toolkit: to avoid having to reinvent parts they're not interested in innovating. Spotify could build an entire UI library which interfaced directly to your graphics card, but nobody would really notice, so they spend their resources elsewhere. – IMSoP Feb 23 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.