Really, is it the first launch after session begin?
If yes, y really want the same computer 
Here is my calculator (just after start my computer)
~$ time snap run gnome-calculator
real 0m10,232s
user 0m0,469s
sys 0m2,794s
cartes@cartes-GA-970A-UD3:~$
10 seconds for calculator, not a 3d software, can you imagine chromium or vlc?
Chromium is not gone as a deb package on most versions… That is not what was announced, and I’ll quote @oSoMoN:
All other supported Ubuntu releases (16.04, 17.10, 18.04) will continue receiving chromium updates.
By the way if you’re running 14.04, you should think about upgrading or buying Canonical support, because that version is otherwise without standard support for several months.
$ time snap run gnome-calculator
real 0m0.671s
user 0m0.232s
sys 0m0.159s
You’re probably not taking into account that the timer doesn’t stop until you close the window. So my 0.67 seconds includes the time for me to react to the window appearing and then closing it.
You don’t need to imagine what VLC or chromium is like. You can test it, and if there’s a problem, report it as a bug.
That’s what snaps offer with many other beneficial extras for their own security and in software availability, and PPA don’t.
Did you try just after booting?
If i do my best to close the window
$ time snap run gnome-calculator
real 0m7,078s
user 0m0,465s
sys 0m2,635s
Then in a second launch
time snap run gnome-calculator
real 0m1,856s
user 0m0,447s
sys 0m0,285s
Then i remove snap and install deb gnome calculator. On the first launch
time gnome-calculator
real 0m1,813s
user 0m0,361s
sys 0m0,037s
it’s 7 times faster.
Ok i’ll do a bug report for calculator, vlc, chromium …
But, the post here is not against SNAP but only to say, for everyday users, this is not ready now.
@diogoconstantino, you’re quoting from a 2018 thread that I originally linked to in order provide an insight into what prompted the move to a snap for Chromium.
Please see the very recent call for testing thread: Call for testing: chromium-browser deb to snap transition where it says that the transition to a snap package will be rolled out to all supported releases in due course:
In a first step, the transition will be happening exclusively for Ubuntu 19.10 (Eoan Ermine) users, and once I’m confident it is rock-solid it will be rolled out to stable releases, starting with disco and then the LTSes.
As I have already said, the problems that originally affected the Trusty release may also be affecting later releases now or will do in the future.
No, I rarely reboot. That’s useful data there.
You can also snap run --trace-exec (snapname) to see what the top 10 most time-consuming system calls. Like this.
$ snap run --trace-exec gnome-calculator
Slowest 10 exec calls during snap run:
0.035s /snap/core/7169/usr/lib/snapd/snap-confine
0.014s /bin/mkdir
0.011s /usr/bin/head
0.013s /usr/bin/realpath
0.010s /usr/bin/realpath
0.012s /usr/bin/realpath
0.011s /usr/bin/realpath
0.013s /usr/bin/realpath
0.014s /bin/mkdir
0.300s /snap/gnome-calculator/406/bin/desktop-launch
Total time: 1.386s
This can be useful data to provide when reporting issues.
One could argue the same about all of desktop Linux 
I’m afraid that you don’t understand that the problem concern the first time you launch the application in the session.
Snaps are experimental stuff, created not thinking of desktop users, maybe good enough for IoT, where one specialised app would only be needed. Btw, who cares for desktop users these days, after all?!
How long does the Calculater snap takes to start, and how long it takes to start the old fashioned, Debian like deb calculator app? A simple app, after all.
The Calculator-snap is not snappy!
The container is making it late – something else has to start for it to start or something like that. @popey
You feel that lateness. Snaps are not ready…yet.
Maybe you should reboot, for most of us do.
Be assured I understand the problem more than you realise. My team has regular meetings with the desktop team and the snapd teams. We discuss these issues very frequently. However, without specific data it’s very difficult to fix anything. It’s incredibly frustrating to be told “This is broken” with no useful actionable data to back it up. If you said to Mozilla “Firefox is slow” you’d be requested for more data. This is no different.
I will personally advocate for you and others to the Ubuntu Desktop team and snapd team, but I can’t do that without something more than “snaps are slow” or “snaps are rubbish” or “snaps don’t work” because that’s useless to everyone.
So, i have updated my bug report with the result of
$ snap run --trace-exec gnome-calculator
Not quite true. There are a number of AUR -bin packages which use the prebuilt binaries provided by debs or RPMs. However, there are from-source versions of the same software also available.
That’s true but, having used Arch for about ten years, my experience is:
Building from source complex packages in the AUR drags lots of from-source build-time dependencies from the AUR itself and the chance of a happy ending significantly decreases.
When the “complex packages” are binaries in the community repo, they tend to be outdated (at least comparing them to third-party PPAs or snap/flatpaks). Also, I’ve had experiences with broken dependencies in complex community packages (for example, mismatched electron versions).
That said, nobody is to blame here, it’s amazing what Arch has achieved with little resources but VERY SMART design decisions: close to upstream, rolling-release, few target architectures, simplistic packaging with centralized user repository, excellent documentation. But the problem Ubuntu faces is very different, it’s not a system oriented to tinkerers and power users. And, as I’ve already said, that Arch sometimes excels at providing a common packaging interface around stuff prepackaged as deb/rpm/snap/flatpak depends, well, on these things existing in the first place. But, by all means, with this I’m not saying Arch is free-riding Debian nor something remotely equivalent!
That’s entirely beside the point. There is this rhetorical device named quoting (exemplified above) and you have misused it, that is to say you have misquoted me. You could have just fixed it instead of trying to justify the unjustifiable.
What’s the point of insisting on the first-launch benchmark? It was acknowledged many times, even in this thread, that this is a shortcoming of snaps. Once you agree there are more advantages than disadvantages, repeatedly mentioning the disadvantages won’t outweigh the advantages. And if you find the balance negative, provide a new argument in order to make the discussion advance.
Ok so the technical rational to do this still makes sense.
This is problematic for all Ubuntu based derivatives. For example pop_os doesn’t use snap at all. How can I keep using chromium-deb on pop_os or are we now forced to use snap ?
sudo apt install snapd
I did. Except it doesn’t work. Doesn’t use default theme. And it crashes for 32 bit.
If you’re seeing crashes, perhaps file a bug so it can be fixed.
The System76 developers could maintain a deb of Chromium in the Pop! OS repo as they do for other applications which they ship and support.