Welcome to Half 2 of our investigation into Firefox snap efficiency. To minimise duplication we advocate testing Half 1 of this sequence. There you’ll discover a abstract of our strategy, glossary of phrases, and tips about standardised benchmarking.
Welcome again, Firefox followers! It’s time for one more replace on our Firefox snap enhancements.
The Firefox snap affords an a variety of benefits to each day customers of Ubuntu in addition to a variety of different Linux distributions. It improves safety, delivers cross-release compatibility and shortens the time for enhancements from Mozilla to get into the fingers of customers.
At present, this strategy has trade-offs relating to efficiency, most notably in Firefox’s first launch after a system reboot. This sequence tracks our progress in enhancing startup occasions to make sure we’re delivering the perfect person expertise potential.
Alongside the way in which we’ll even be addressing particular use-case points which have been recognized with the assistance of the group.
Let’s check out what’s we’ve been as much as!
Present areas of focus
Right here we cowl latest fixes, newly recognized areas of curiosity and an replace on our profiling investigations.
Jupyter Pocket book assist – FIXED
For numerous information scientists, Jupyter Pocket book assist within the browser is vital to their workflow. When launching a pocket book there are two methods to view it:
- Opening a file at ~/.native/share/jupyter/…
- Navigating to an http://localhost/ URL
The second route is extra compliant with sandboxed environments and has no points within the Firefox snap. Nevertheless, the default advice is to open the file straight. This precipitated issues since .native isn’t accessible to confined snaps, which restrict entry to dot directories by default.
We now have merged a snapd workaround giving the browser interface entry particularly to ~/.native/share/jupyter to allow the default workflow. We additionally reported the difficulty upstream and advised altering the assistance textual content to level to the http://localhost/ URL first because the really useful person journey.
Software program rendering
Final time, we talked in regards to the Firefox snap failing to find out which GPU driver it ought to use. On this circumstance it falls again to software program rendering on gadgets just like the Raspberry Pi, which considerably impacts efficiency. To deal with this we’ve up to date the snapd OpenGL interface to permit entry to extra PCI IDs, together with those used on the Rasberry Pi.
Nevertheless, this repair doesn’t appear to completely tackle the difficulty. There are nonetheless experiences of acceleration being blocked by the platform. Resolving this has the potential to make a big distinction on Raspberry Pi so we’re persevering with to analyze.
Extension dealing with
Copying the massive variety of language packs throughout Firefox’s first begin stays a constant difficulty in all of our benchmarks.
Mozilla intend to reflect a change within the snap that they made on the Home windows model of Firefox. This could add the flexibility to solely load one locale at a time based mostly on the system locale.
Native messaging assist
Native messaging assist permits key options corresponding to 2FA gadgets and GNOME extensions. The brand new XDG Desktop Portal has landed in Jammy however the Firefox integration continues to be iterated on. Issues are progressing nicely and the repair ought to land quickly.
Community Mounts
The Firefox snap and flatpak are at present unable to work together with community shares. This drawback has to do with the XDG Desktop Portal working in native mode. The truth that the fileselector portal is itemizing these mounts in the sidebar can also be including to the confusion.
Till the portal difficulty will get resolved, one workaround is to entry the mount via /var/run/person/USERUID/gvfs (NOTE: you want gvfs-fuse put in, which creates native mount factors).
Font and icon dealing with
New benchmarks for font and icon dealing with on amd64 recommend that the cache constructing of icons, themes and fonts is comparatively minor relating to useful resource utilization. Firefox spends a while doing this, whereas Chromium doesn’t. For many methods that is round 300ms, however on Raspberry Pi the affect is way bigger (as much as 6-7 seconds).
Investigations present that the caching course of could be very I/O intensive, and I/O is so much slower on an SD card with a Raspberry Pi 4 CPU.
That is possible a symptom of an underlying difficulty that we’re working to establish.
Futex() syscall time
We analyzed the conduct of the confined snap of Firefox towards the unconfined model, in addition to the Firefox setup confined from the tarball (out there as a direct obtain from the Mozilla web site).
With the confined model, within the strace run summaries, we seen that the futex() system name takes about 20000us to finish on common on Kubuntu 22.04 and about 7000us on Fedora 36, each put in on equivalent {hardware}. These numbers point out reminiscence locking rivalry, particularly when in comparison with the identical outcomes gathered from the unconfined or non-snap variations of Firefox. There, the futex() system name averages solely about 20us
Moreover, we seen that the snap model executes way more futex() system calls (in addition to others). A few of that is anticipated, because the execution of the snap differs from non-snap purposes, together with using base and content material snaps, in addition to safety confinement
The issue has been reported constantly on totally different {hardware} platforms and Linux distributions, with the general futex() system name common time correlating linearly with the noticed startup time.
As an illustration, a pattern strace abstract (strace -c) of a Firefox snap run:
% time seconds usecs/name calls errors syscall
------ ----------- ----------- --------- --------- -------------------
82.18 388.576521 18131 21431 2272 futex
10.31 48.737839 7583 6427 4 ballot
4.09 19.350524 7660 2526 6 epoll_wait
1.50 7.114924 72601 98 38 wait4
0.69 3.258415 574 5676 2715 recvmsg
0.51 2.406544 41492 58 clock_nanosleep
0.13 0.633050 71 8843 5 learn
0.12 0.564651 34 16452 11403 openatAnd as compared, the tar model on the identical host:
% time seconds usecs/name calls errors syscall
------ ----------- ----------- --------- --------- -------------------
46.13 0.397783 8 47957 clock_gettime
19.76 0.170379 21 7828 1245 futex
6.90 0.059470 8 6888 gettimeofday
5.22 0.044991 8 5353 4324 recvmsg
3.49 0.030111 8 3745 ballot
2.57 0.022125 22125 1 wait4
1.75 0.015092 8 1829 learn
1.68 0.014518 15 942 319 openatWe now have noticed comparable outcomes with different snaps, together with Thunderbird in addition to Chromium. Whereas the precise startup time differs from snap to snap, the general conduct is constant, and underlines an extra of computation with snap binaries
We tried to isolate the supply of this phenomenon in several methods. First, we tried to know whether or not the safety confinement could also be the reason for no matter rivalry in reminiscence administration would trigger Firefox (and different binaries) to expertise userspace locking points. This could then translate into the surplus of futex() system calls and their subsequently very excessive time per name. Disabling the AppArmor and Seccomp confinement didn’t yield any enhancements.
Likewise, we compiled Firefox with its inner sandboxing disabled, in addition to compiled the browser with using tmalloc (to know if there could also be different causes for reminiscence rivalry), however these makes an attempt additionally didn’t yield any startup time enhancements
We’re persevering with to discover this difficulty with additional strace and reminiscence checks towards a non-confined snapd model.
Communicate
That’s all for this week’s replace! Look out for Half 3 within the subsequent few weeks. Within the meantime don’t neglect to keep watch over our key aggregators of points and suggestions:
If you wish to take benchmarks and monitor enhancements by yourself machine, don’t neglect to learn our part ‘Create your personal benchmarks’ in Half 1 of this sequence and share them on our Discourse matter.
