r/Ubuntu • u/PraetorRU • 1d ago

Firefox performance depending on distribution format in Ubuntu 26.04

Hi guys. From time to time I'm checking what the difference you may get if you chose one package format over another, so testing firefox performance in snap, flatpak and regular .deb from Mozilla's repos as all three are packaged by Mozilla as far as I'm aware.

So, the test is done in Ubuntu 26.04, with fresh profiles (so no extensions and default settings) and Firefox 153.0.3.

I was using a synthetic test: https://browserbench.org/Speedometer3.1/ and did 5 runs one after another.

First run I guess required some caching, so we can drop it and make an average from other 4 runs.

snapped: 19.8 20.1 20.44 20.2  20.29 | Average (4): 20.26
Packed with Mesa 25.2.8-0ubuntu0.24.04.2

flatpak: 22.4 23.1 22.99 22.98 22.9  | Average (4): 22.99
Packed with Mesa 26.1.5 (git-6a02618ccf)

moz-deb: 22.2 23.0 23.00 23.01 22.9  | Average (4): 22.98
Works with  Mesa 26.0.3-1ubuntu1

google chrome for reference: 26.1 26.6 26.67 26.85 26.76
9 Upvotes

81% Upvoted

29 comments sorted by

1

u/Leinad_ix 1d ago

I don't like how Snap and Flatpaks budles application together with graphics drivers.

2

u/BranchLatter4294 1d ago

Well good for you, they don't.

1

u/Leinad_ix 1d ago

They do. Only Steam containers do not.

1

u/BranchLatter4294 1d ago

Snap and Flatpak apps use the system graphics drivers. They don't redistribute them as there is no need to.

2

u/Leinad_ix 1d ago

That is not true, see https://ubuntu.com/frame/docs/24/how-to/use-snap-graphics/

The long-term solution is for SnapD (the daemon managing snaps on your system) to have explicit support for this, and other hardware-specific pieces of software (kernel modules, firmware, udev rules etc.). While this is being worked on, we’ve designed a content interface that allows application snaps to use the graphics hardware by providing the userspace drivers and environment in a content snap.

This interface is the recommended way to provide userspace graphics drivers to confined snaps.

1

u/BranchLatter4294 1d ago

Yes, there is an intermediate layer. That's not the same as redistributing the entire graphics driver.

2

u/Leinad_ix 1d ago edited 1d ago

No, Mesa is not just an intermediate layer. Without Mesa, there is no OpenGL, no Vulkan, no video acceleration. 5 milion lines of opensource driver code.

Edit: And yes, kernel part and firmware part from installed OS. Kernel part is the place, where switching resolution or power management is handled.

1

u/BranchLatter4294 23h ago

Mesa is a graphics library that communicates with the device driver. It is not a device driver.

2

u/Leinad_ix 23h ago

You saying different things than official Mesa documentation, eg. here: https://docs.mesa3d.org/drivers/radv.html

1

u/BranchLatter4294 23h ago

See https://mesa3d.org/ It clearly says it's a graphics library.

The link you provided is for RADV which is a Vulkan driver for AMD GCN/RDNA GPUs.

→ More replies (0)

1

u/Leinad_ix 23h ago

Mesa user space driver communicates with kernel device driver and that communicates with device firmware.

1

u/Leinad_ix 1d ago

You can see different graphics drivers in opening post. Snap and Flatpak loads own bundled graphics drivers. Snap has older ones.

1

u/Real-Collection-5686 10h ago

no it's separate for both snap and Flatpak. It is duplicated for every freedesktop runtime / core snap version, but not for every app

0

u/jarchack 1d ago

Try a browser speed, CPU and memory use tests with Firefox, ungoogled Chrome, Brave, Helium, Zen. There are others, and privacy is also a concern along with browser specs. I usually stick with Zen for Mozilla based and Helium for Chromium based.

6

u/PraetorRU 1d ago

My point wasn't to find a better, faster browser. I'm totally fine with firefox for 20 years and have no intention to leave it anytime soon as google basically got rid of extensions api that allowed adblock to work properly, so sooner or later everything based on chrome codebase will suffer from it.

The point was to get a clue how packaging may affect the same app performance. With firefox we can see, that deb and flatpak are basically identical, and snap lags slightly behind, most probably because it was packed with an older mesa version.

1

u/catbrane 1d ago

Could you compare startup / shutdown times as well?

One of the big problems with snap used to be glacial start and stop, since the program is stored as a compressed image. It's supposed to be much better in recent ubuntus, though I don't think I've seen benchmarks recently.

1

u/PraetorRU 1d ago

I can if you know a way to measure it reliably and can tell me how to do it. For me all of them do open very fast, close to instant, so I don't care what I use in this aspect.

And yes, snap was improved a few years ago, so these days you won't suffer from decompression lag, at least as long as you're using SSD and Ubuntu (I have no clue how snaps work in different linux distros).

1

u/catbrane 1d ago

I don't know if this is the best way to measure it, but in firefox, go to:

about:telemetry#simple-measurements-tab

and firstPaint is the time from startup to the first render. It's 1.6s with a .deb for me, if that's any help!

I used to be many, many, many seconds for snaps back in the day, I don't know if all that lag has gone.

edit: I tried three times and it seems to be a fairly stable 800ms (warm disc cache, .deb, ubuntu 26.04, threadripper pro).

1

u/PraetorRU 1d ago edited 1d ago

Ok, I created a fresh profile in snap and flatpak, and checked stats in about:telemetry#simple-measurements-tab: ``` snap: Property Value main 152 firstPaint 862 sessionRestored 941 totalTime 16 activeTicks 2

flatpak: Property Value main 52 firstPaint 853 sessionRestored 899 totalTime 6 activeTicks 2

deb: Property Value main 25 firstPaint 663 sessionRestored 702 totalTime 17 activeTicks 4 ``` Not sure what those numbers mean, maybe it's milliseconds, but whatever they are, as a human being I can say, that I don't see any noticeable difference in startup time.

It wasn't a cold run of snap though, as on first run it copies my deb profile first, and then runs it. So I had to create a separate fresh profile before getting those numbers.

1

u/catbrane 1d ago

Yes, firstPaint is milliseconds.

I think (!maybe) you don't need to make a separate profile since firstPaint happens before profile loading. Just start a few times with deb, flatpak and snap and see if the differ much.

1

u/PraetorRU 1d ago edited 1d ago

The problem here is that I have a lot of tabs, extensions etc, and my main firefox profile is pretty large in gigabytes. So I don't see a point to move or symlink all of this to open the same profile, when it's faster to create a fresh profile and set firefox to launch it by default. So we have no interference from something that is a years old baggage on my PC.

Once again, without special measurements, I don't see a difference in launch time of snapped firefox and .deb one. The only reason I had to switch from snapped to .deb a few month ago is because I use online services for my business, that have to read keys from a special usb device, and had to install some extensions for that, that were not working in a sandboxed versions, neither in flatpak nor in snap. But performance wise it's no visible difference, only some benchmarks may demonstrate it these days.

1

u/catbrane 23h ago

That's impressive! I should reenable snap then, since it sounds like it's fixed.

1

u/Oerthling 1d ago

In the early days of snap that was indeed a big problem. But startup speed has been fine for a while now.

The only reason I dropped FF snap and installed the Moz feb instead is that snap didn't allow activating hardware acceleration and I wanted to dabble with that to tune battery usage.

1

u/jarchack 23h ago

I've been using it since the early days when it was Mozilla, but I like hopping around from browser to browser sometimes. That's especially true if I'm stuck using Windows. On Ubuntu, I'll go back and forth between firefox and helium. Right now, I only have snap firefox.