Improving Firefox Responsiveness on macOS
hacks.mozilla.org
hacks.mozilla.org
With all the things they've addressed in Firefox recently and with Chrome's manifest v3 nonsense, I'm running out of reasons not to switch.
Firefox is supposed to get that too. Believe it's in Nightly already.
- better privacy protections
- not wanting to leave web standards entirely to Google/Apple (for-profit corps)
Brave attempts to address the first, but does little about the second as it uses Blink (i.e. Chrome's engine). Personally, I care a lot more about the second.
They’re not wives, you can have more than one.
Firefox will have no such problem, as Mozilla has specifically committed to keeping the necessary features.
It does in theory also help block some malicious sites so you do get a bit of added security in that way. That can also be helpful if you have kids - block sites you don't want them on etc.
Personally I've also found their servers to be reasonably performant, no issues with query response times or anything like that.
But now that I'm using native tabs, it is much easier for me to use multiple windows because the tabs are attached. Thanks for pointing this out!
It's Chrome dominating, Webkit a somewhat distant second [1], and Firefox a third, quickly disappearing into oblivion [2].
[1] There's a huge number of weird versions of WebKit running on TVs and such.
[2] It's barely around 200M users, but it's bleeding users slowly and surely https://data.firefox.com/dashboard/user-activity and https://news.itsfoss.com/firefox-decline/
* Blink (Google)
* WebKit2 (Apple and some folks, mainly WebKit2Gtk)
* Gecko (Mozilla)
Microsofts Trident is dead, they now use Blink.
Operas Presto is dead, they now use Blink.
KDEs KHTML (the predecessor of WebKit1) is dead.
WebKit features also WebKit2Gtk (Epiphany) and Qt5-webkit (Otter) with native integration. Both use the native toolkits, which is an advantage! Interaction with the open-source community around WebKit seems rather good and the engine is integrated by others. Gecko seems not to be integrated by others but by forks only? You remember when Chrome was considered slick and fast? Originally Chrome used the native toolkit on every platform. Now Chrome ships an own toolkit, similar to Firefox.
And? Maybe there is a new engine on the block:
https://github.com/SerenityOS/ladybird
PS: I think the Epiphany guys doing a nice job but need more developers. The upcoming release will support Web-Extensions.
Granted, that was more about mobile devices but it still stuck with me. Effortless and safe concurrency would tip the scales to having hundreds of low power cores instead of a dozen high powered cores. I want that world, esp for mobile devices and laptops.
Unfortunately nothing had improved by the time I left in 2021.
Bonus: Charging your mobile phone takes less percents off your battery life than with a macbook.
Did they work? Yes! Performance on lightly loaded systems was about the same as OSSpinLock but on loaded ones, they provided massively better responsiveness. They also did something extremely useful for laptop users: they cut down power consumption as a lot less cycles were wasted having the CPUs spinning on locks that couldn’t be acquired.
I have a web app that allows customers to make templates for their standard operating procedures that they pull from our main product. For writing steps and substeps, I use a WYSIWYG HTML editor called TynyMCE. I went with it because I was able to implement it in an afternoon, their licensing was compatible with our use, and I had a tight deadline.
We failed to anticipate just how large some of the templates clients would be making, so sometimes when they open a template they end up having a couple hundred of these editors hidden behind drag and drop enabled accordions.
Firefox chokes on the initial TinyMCE calls for these large templates, taking quite a long time to fully render the page. Once it's done, everything is nice and snappy, but it's like a 20-30 second wait after the wire even on my beefy 5900x.
Chrome seems to handle this just fine.
It's possible that the culprit is a bad polyfill or a Firefox-specific bug in TinyMCE, I haven't put much work into diagnosing it yet beyond verifying that TinyMCE is eating up all the CPU time. For now my planned solution is to just write my own WYSIWYG editor, because TinyMCE ultimately offers a lot more than we actually need, and it was only a stopgap solution to get out a polished MVP. But needless to say, for the first time in years, I found myself spending a non-trivial amount of development time in Chrome. Sadly I've never actually had a client use this app with anything other than Chrome or Safari, so this is naturally a low-priority issue.
Here are instructions of using the profiler with just a few clicks: https://profiler.firefox.com/
I am sure Mozilla would appreciate a bug filed in Bugzilla if you can.
The Firefox Profiler is an amazing piece of work. It's my tool of choice even for non-Firefox scenarios, since it can load in perf profiles (and even Chrome profiles, though I haven't tried that). It has grown into a general profiler front-end, and continues to see significant improvements. I have heard of a number of people adopting it as their system profiler of choice for arbitrary workloads, not just browser-related ones.
(I work at Mozilla, but not on the profiler. At least not most of the time. I've added some small things in to give it more information about my specific subsystem. I have enormous respect for the work going into the profiler, both the functionality and design.)
The reason TinyMCE won out was because they made self-hosting easy under license terms that my employer was OK with, and wrapping the whole thing in a Vue component only took me a few hours.
FWIW, TinyMCE is a bit long in the tooth these days. I implemented my own from-scratch WYSIWYG editor back in 2010, and it wasn’t even the best option then (ckEditor was much better), and many people were using the unreliable lightweight jquery based editors because TinyMCE was considered too heavyweight.
I wouldn’t like to say for sure that’s it’s the source of your problems (Firefox’s contenteditable implementation is also “quirky”), but it could well be.
What if you only loaded/initialized the editors when they became visible?
For your own mental health, don’t. I was looking for an old article describing how bad the API is, written by one of the authors of a WYSIWYG JS editor, but I can’t find it.
Or
https://medium.engineering/why-contenteditable-is-terrible-1...
Are two that I remember reading... nearly 10 years ago, holy hell can someone please make time slow down? Which discuss the common API pitfalls with `contenteditable` -- though I've no idea how painful it is in 2022. Could be a lot better now?
> Could be a lot better now?
Effectively zero progress. Last year I heard some work being done on an alternative API but I haven’t see that since. I don’t expect anything to be done before 2025 if ever.
Basically it just lets you extend how many roles/accounts you can switch between in the AWS console UI.
Also keep in mind although Firefox containers is made by Mozilla it's a plugin that you have install, which was very counter intuitive when I first wanted to use it.
I believe Apple is doing something similar with their virtualization API - it's there, some folks can use it, but they don't want to surface it to the masses.
In practice, it feels like that has hurt adoption. You can't pave the cowpaths if the cows aren't venturing out of the corner of the field.
Someone should make an automated Unmozilla’d Firefox that rips out all phone-home and advertising. I’d run that.
I leave Safari as my default browser, although I actually use it the least. But I like having the same "default" experience on my desktop and phone. If I am opening a link from Mail.app or punching something into Alfred it will open in Safari. I use some light ad-blocking. I use Chrome for work. I use Google Translate a bit and this works extra well in Chrome. Plus, Google apps and whatnot. Limited ad-blocking because I'm often using ads platforms. I use Firefox for all my intentional/casual browsing. Maximum ad blocking.
Adblock Plus, Ghostery, and Hush on macOS.
(/rant)
I know this it heresy to say on HN, especially coming from someone who whines about gov surveillance as much as the next person, but I personally love YouTube's recommendation system. And I know from experience it uses what you actually spend time watching to make recommendations (not just what you click on). So I'd personally miss having them be able to measure that...
I feel like YouTube knows me better than any other service I use (besides maybe Spotify which also measures what you actually listen to) and I pay to be a YT subscriber so I don't se ads on iOS mobile (jailbreaking doesn't provide with me ROI).
I hear a lot of HNers complain YouTube recommends conspiracy or negative politics stuff (see: Twitter and Reddit for that who also completely suck at recommendation systems despite aggressive analytics) but to me it sounds like a) they don't actually use YouTube often enough to tell it what you want or b) they are using blockers/not logged in so it can't learn what you like.
BUT THAT BEING SAID, getting to use a minimalist <video> tag sounds very nice otherwise.
It's not a direct apples to apples comparison, but my anecdotal evidence, on Linux, is the opposite. I usually use Firefox on my Linux/X11 box, but every now and again I fire up Chromium and always get the feeling that it's much snappier.
* CPU Usage is extremely higher than in chrome for video call/meeting related websites.
* Font rendering is horrible on a lot of websites. I think this is more fault of the website developers, but it doesn't change the fact that I as end user with Firefox have subpar experience.
* The native OS integration seems very janky, from swipe to go back, to pinch to zoom, something feels off about them.
* I've encountered a lot more websites that didn't quite work smoothly. This is same as one of the points above of web developers being at fault here, but it still doesn't change my experience with FF.
I want to use Firefox, but not if it degrades my experience - which it currently very noticeably does.
> At this point, you might wonder if os_unfair_lock – possibly coupled with the undocumented flags – would be a good fit for your codebase. My answer is likely yes but you’ll have to be careful when using it.
I would hesitate to give this advice. The overwhelming majority of applications on macOS do not have performance profiles like Firefox does. The system allocator (rather than jemalloc) is the right choice for all but very few use cases. There are a vanishingly small number of usecases where using the undocumented flags is appropriate.
The rules are different when you’re a popular browser with an existing relationship with Apple and dozens of smart engineers who can (at least in theory) understand the consequences of using this API, and leverage an existing relationship with Apple to ensure that it doesn’t become a liability in the future as the platform evolves. For pretty much everyone else, this should be nothing more than a “wow, neat” blog post.
I sincerely doubt that Firefox can leverage anything with Apple, or that Firefox engineers have much of a relationship at all with Apple. Who does, really.
I'm not sure it matters though. Many smaller Mac developers have a long history of using private API, and it's largely fine. There's no truly "safe path" with Apple, because Apple does whatever it wants whenever it wants, and I've seen them break "supported" API plenty of times, and leave it in a broken state. But the risks of any given brokenness are small, and you can't predict what will break from year to year, so what can you do except go with what works, and hope for the best.
It's certainly fair to say that the majority of applications on macOS do not have the performance profiles of Firefox, but it's also the case that the majority of applications weren't even using lower level primitives like OSSpinLock in the first place, so replacing it was not a concern.
The target for this comment is developers like you, but those who are less familiar with the platform than you are but of similar import. Those are the ones who will read this and say “wow Firefox says this is how to make my app fast so I should do it!!1!” and what is going to happen is either they’re going to use it wrong, because they aren’t really experts on how locking works, or they’ll copy the code of of Firefox and their app will break in a future OS release while Mozilla will update their code in July.
You can't save people from themselves, but in any case this seems to overlook what I said at the end: "the majority of applications weren't even using lower level primitives like OSSpinLock in the first place, so replacing it was not a concern."
I wouldn't worry about native Mac developers, who I suspect are mostly a dying breed of grizzled old veterans nowadays. To illustrate, I noticed recently that the last post on https://www.reddit.com/r/macprogramming/ was over 2 years ago, April 2020.
Granted Swift is technically a cross platform language but it feels safe to assume that the vast majority of users are developing for macOS and iOS.
The vast majority of Swift users are developing for iOS.
The article is about macOS and private API. Thus it's only relevant to a small subset of developers who write native Mac software distributed outside the App Store.
Note that https://www.reddit.com/r/iOSProgramming/ is itself also extremely active with posts within the last hour, so it's strange to cite r/Swift as evidence of Mac activity.
What exactly do you think I'm mistaken about? The conclusion of your sentence doesn't follow logically from the first clause.
The readers of your comment here know nothing about this macOS project or the contributor who sent you a message. In any case, there's a vast gulf between someone sending you a message and someone actually writing and releasing bad code.
You really don't want the rest of the OS making the performance trade offs people expect from browser engines these days.
The function this article is talking about is not API, it is part of the OS internals, presumably used to implement the standard API functions.
However those are not suitable for use in the memory allocator, and neither are WebKit's. WebKit uses os_unfair_lock within its memory allocator:
https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de995...
And so does Chromium:
https://source.chromium.org/chromium/chromium/src/+/main:bas...
This article is about an internal function in the OS that they've decided to is what they'd like to use, and that the only reason they aren't using it is because it doesn't exist in older versions of macOS, because you know, it is an implementation detail of the OS.
os_unfair_lock are a documented part of the OS API: https://developer.apple.com/documentation/os/1646466-os_unfa...
From some Zig code:
// Darwin XNU 7195.50.7.100.1 introduced __ulock_wait2 and migrated code paths (notably pthread_cond_t) towards it:
// https://github.com/apple/darwin-xnu/commit/d4061fb0260b3ed486147341b72468f836ed6c8f#diff-08f993cc40af475663274687b7c326cc6c3031e0db3ac8de7b24624610616be6
//
// This XNU version appears to correspond to 11.0.1:
// https://kernelshaman.blogspot.com/2021/01/building-xnu-for-macos-big-sur-1101.html
//
// ulock_wait() uses 32-bit micro-second timeouts where 0 = INFINITE or no-timeout
// ulock_wait2() uses 64-bit nano-second timeouts (with the same convention)To me it has always seemed as a decent strategy, and when working on a cross-platform heavily multi-threaded code base which had a fairly contested hot-spot, Windows performed quite well using just plain critical sections.
[1]: https://learn.microsoft.com/en-us/windows/win32/sync/critica...
This is why you can’t download WireGuard from the WireGuard website. You have to identify yourself to Apple with an Apple ID (which requires a non-disposable email and working phone number) to download free privacy software.
I'm not sure that's entirely true. It's really a matter of how the extension is packaged: app extension for App Store or system extension for Developer ID.
"On macOS most Network Extension provider types can be packaged as either an app extension or a system extension. App extensions run in a user context; if the user logs out, the provider is terminated. System extensions run in a global context, completely independent of the logged in user." https://developer.apple.com/documentation/technotes/tn3134-n...
It is the case that Safari web extensions are Mac App Store only, as opposed to Safari app extensions, which can be Developer ID.
I think the problem is locking us to one app store - because the app store does provide some added functionality (easy of use - one place to go for all apps - security vetting - automated update settings across apps)
App stores allow users a centralized place to both acquire known and verified applications as well as get updates for them. They are a safe place to buy things - Apple is not going to steal your credit card. For developers, they are a convenient place to park your app, without having to manage your own distribution services. And payments is always pain - it's probably the single biggest value add that the app stores cover it for you.
And you can always circumvent it on these platforms. It's just an addition. I'd prefer to get an app on the mac app store if it is there, if it is not then that is fine as well, but will require more digging to verify it's authenticity.
iOS App Store too. They're not safe. Apple isn't going to steal your credit card, but they'll happily charge your credit card for these scams.
App stores are distribution mechanisms and advertisement channels, same value proposition as Spotify compared to shipping your music on your own website.
1. Switching on/off VPN would hamper the connectivity (sometimes only), not sure if this specific to my network
2. Responsiveness is an issue, key type response is slower. I will check if this new version helps.
Thanks FF team for your efforts.
A lot of times, I have to close the current tab and open a new one to regain connectivity.
It is my only issue with Firefox on mac, currently.
When I disconnect from VPN, Firefox still has the VPN's proxy settings. I have to restart it to refresh Firefox's cached proxy settings. So that means I effectively have to restart Firefox any time I change between VPN and non-VPN.
If that's your problem too, then I don't have a fix for it. I'd love to hear if anybody else does though.
I haven't had an issue with Firefox with that.
Are you doing something nicer than manually flipping location or going into the network settings and turning the proxy on/off?
You could also manually specify a DNS provider like Cloudflare or NextDNS on the personal user for DoH / DoT
https://addons.mozilla.org/en-US/firefox/addon/switchyomega/
Huh, now that you say it: I haven't been all that angry at Firefox lately.
I think I also don’t understand the discussion about spinning in kernel space. Doesn’t that require context switches which the article points out have issues? I would have guessed the answer would be to spin a bit in userspace with architecture-specific instructions like pause and then syscall if the lock couldn’t be acquired. Maybe I just don’t really know how syscalls work on a Mac.
I’m also weakly curious why jemalloc needs so much locking anyway? I haven’t thought about this at all so I’m surely missing something but my guess would be allocation from per-thread pools with occasional synchronisation, and that this synchronisation would be too infrequent to have these issues.
Spinning in kernel space does require a transition into the kernel. But, critically, it does not require rescheduling another thread and waiting around, which is even more expensive. The kernel has the context to know what is running and what isn’t, as well as some information on who owns the lock, so it can do a pretty good job here. Spinning in userspace is bad because the thread holding the lock may be parked by the kernel, which means that you’re just spinning for no reason. If you don’t include any special instructions you burn power, and even if you do you don’t benefit from the knowledge the kernel has of whether you should just be scheduled off while waiting anyways.
I'd love to hear from someone with more firsthand knowledge, but from a quick read of the implementation details for jemalloc, it seems there is a balance that has to be struck between lock contention and memory fragmentation. Too few arenas and lock contention slows you down, too many arenas (or enabling thread-specific caches) and the cache misses from fragmentation will slow you down.
the blog post also mentioned that Firefox's jemalloc is highly customized, maybe firefox's specific profile gets value out of a more lock-heavy strategy.
https://jemalloc.net/jemalloc.3.html (see "Implementation Notes")
[edit] Could be this Twitter thread that I have in mind: https://twitter.com/gabrielesvelto/status/155808346105915392...
It's really the only browser left that let's you do deep customization. With the right settings (not that many) you can basically strip it of all bloat. And of course it will be the last (big) browser with full Ubo support when Google introduces Manifest 3 (Ubo was also the reason I switched from Safari to Firefox).
I'm in the same situation as a lot of others here, where I'm thinking about permanently migrating back to Firefox after Chrome takes their Manifest v3 + WebRequest API changes live, and I'd love to know how I can improve the performance of Firefox & ensure my configuration is as good as it can be.
I personally use it to quickly bookmark things in a cross-platform "i'll look at this later" box (although not a fan of how it tries to show me pages in-app). Recommendations for alternatives would be equally accepted.
I'm sorry, but credit card advertisements are not stories. For the first time ever, I turned off the Pocket section, which means that instead of generating some revenue from having clicked on stories in the past, I will now generate no revenue because I won't see this section at all.
Remove FF sync:
identity.fxaccounts.enabled
Remove recommendations in Extensions:
extensions.htmlaboutaddons.recommendations.enabled
Remove recommendations Side panel in Extensions:
extensions.getAddons.showPane (add +set to false)
Remove VPN Promo and More from Mozilla in Settings:
browser.vpn_promo.enabled
browser.preferences.moreFromMozilla
Remove Pocket:
extensions.pocket.enabled
Remove Focus promo in private tabs:
browser.promo.focus.enabled
Remove persistent topsites (facebook, amazon, etc.):
browser.newtabpage.activity-stream.default.sites (clear)
Bonus:
Pinch to zoom only:
mousewheel.with_control.action (1)
Full screen video like Safari:
full-screen-api.macos-native-full-screen
Calculator in tab bar:
browser.urlbar.suggest.calculator
Turning off random browser features only works if you accept that you'll break random websites and won't know why without debugging each one.
This has been my experience over the years every time I've attempted to switch back from Chrome to Firefox.
> If you could grab a profile of the problem with the Firefox profiler and file a bug it would be greatly appreciated. From the sounds of it it's probably an edge-case we're not aware of where Firefox performs very poorly. The problem with this kind of things in Mozilla is that we're often blind until someone brings up the issue and notifies us.
https://news.ycombinator.com/item?id=33156379
> Here are instructions of using the profiler with just a few clicks: https://profiler.firefox.com/
Especially if you're an org with the pedigree of Mozilla.
No it is not fine. Using vertical tab navigation was painful and slowed me down.
Then finally gave up Firefox (after using for 15+ years) when Chrome released tab groups. Use above workaround to believe me that I tried before giving up.
Curious why you'd want this?
https://github.com/gorhill/uBlock/releases shows many recent releases?
Sigh.
1: https://orionfeedback.org/d/149-poor-audio-quality-when-play...
(I was reading https://bugzilla.mozilla.org/show_bug.cgi?id=1736878, which suggested VP9 is not yet there.)
Not always, but often.
You can start with your description and end with "I'd like to help, but I don't have the knowledge how to debug this further. I'm happy to provide more information if you can guide me."
The first thing you'll be pointed at is likely https://profiler.firefox.com/docs/#/./guide-getting-started so it may be a good idea to start with capturing the "idle" profile for a while and submitting that with your initial report. Check the "Share a profile" section.
Out of curiosity, does Chromium use spinlocks on macOS? If they do in a scenario where characteristics need to be similar to the jemalloc use case, how are they accomplishing the outcome?
It uses plain os_unfair_lock: https://chromium.googlesource.com/chromium/src.git/+/refs/he...
EDIT: It also combines os_unfair_lock with manual PAUSE spinning.
I get the occasional tab freeze / crash, and it has some glitches with Google Docs / Sheets, but it just feels so much faster and uses much less RAM too
Under the covers Chrome uses futex on Linux, SRWlock on Windows and os_unfair_lock (not _with_options) on MacOS.
> Memory allocators have to be thread safe and – in order to be performant – need to be able to serve a large number of concurrent requests from different threads.
Another approach is to create a bunch of individual allocators that all hold onto a big chunk of memory that only a small set of threads (or even one thread) use. These allocators only contend for locks with each other when they need to fetch more memory from the OS. Otherwise, they just hold onto the big slab of memory they've allocated, give it out when needed, and when it's "deallocated" they keep holding onto it instead of handing it back to the OS, under the expectation that the thread (or small pool of threads) they're managing memory for will need more again soon.
The only downside to this approach is that over time, the app ends up holding onto tons of memory it's not using right now, on the assumption it will be needed in the future.
Ever notice how Chrome eats memory like it's a three-year-old at an ice cream buffet? That performance ain't free.
Any thread-safe allocator is constantly fighting to be as efficient as possible with its synchronization, because that allows it reduces the amount of trading memory for concurrency/efficiency.
...and while Chrome's PartitionAlloc is different from Firefox's modified JEMalloc, there's a lot of similarity in how the two allocators try to manage concurrency.
One problem with the x86 pause instruction is the number of cycles spent paused has varied dramatically from one CPU to another. Some CPU models ignore it. On others it is very short, a few or ten cycles, and on some it is hundreds of cycles. So you need a startup calibration that measures it, otherwise it will have a random outcome.
Most high performance implementations don't need to operate under that limitation.
1) optional features such as statistics tracking or diagnostics (e.g., the ability to traverse all held locks in the process)
2) A space optimization to keep the lock object very small if uncontended, only allocating ancillary data structures on the heap needed to block at the OS level when contention is detected.
You can easily avoid this: don't support (1) in your specific malloc lock, and don't apply the optimization (2): just put those fields in the main structure.
In any case, no fancy lock is needed either: really they just want a vanilla "userspace aquire + userspace limited spin + fallback to OS blocking primitive" which is pretty much strictly better than their "userspace aquire + forever spin" existing lock. I don't think this is hard to do at all unless the OS-level locking primitives are very strange on OSX.
Here's a previous HN discussion about that (in particular Skylake CPUs greatly diverging from previous behaviour):
https://news.ycombinator.com/item?id=17336853
Original link:
https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpu...
The very latest Intel "client" parts have UMWAIT, which allows a thread to sleep until the TSC reaches a given value, or monitored range of addresses is stored. It's the best of both worlds: a thread can arm the monitor using the address of the lock, and sleep for a defined time. If the lock is released the thread will wake immediately. If not, the thread will wake at a predictable time. This feature isn't widespread and very few libraries on github use it.
But the problem they're working on here isn't the calibration problem. It's about getting the spin/sleep/context switch semantics they want out of the OS.
Came here to say this.
> So you need a startup calibration that measures it, otherwise it will have a random outcome.
I guess one question is if AMD or Intel plan to make any other CPUs with "fast" PAUSE. Looks like Intel has been consistently using the "slow" version since Skylake including on their little cores, while AMD has gone slow much more recently starting in Zen 2.
A reasonable approach with "slow" PAUSE expected but still with large gen-to-gen variation in timing would be to base your spin on a time period, e.g., measured with RDTSC after every PAUSE, rather than a spin count, which should generally preserve the spin interval at least measured in wall clock time.
This would have been a bad solution with "fast" PAUSE though since the cost of the RDTSC would have dwarfed the pause, so you might lose the "minimize load on the hardware thread" part of the PAUSE effect. Though I would question how good the "fast" PAUSE was at that anyway: perhaps RDTSC alone would be a fine substitute: it executes even slightly fewer uops/cycle than PAUSE on Haswell!
It would be nice if slow PAUSE returned a cycle counter or RDTSC-like time counter to enable this kind of spinning. Or maybe UMWAIT just obsoletes all of these spinning approaches? I haven't gotten to play with it yet.
Firefox on Mac user for a very very long time, multiple machines, multiple profiles, multiple containers.
Any chance it's a side effect of an extension you add habitually?
Whilst many like to have a lot of tabs open, I rarely surf that way. If something's interesting, I don't hoard it away in a tab. I have a Pinboard.in bookmarklet I use and tuck it away in there for perusal at a later stage. If the page is no longer needed, I close the tab and continue working.
It used to work fine, but then it became completely unresponsive. There are some options to restore the old behaviour ((gfx.webrender.force-disabled, gfx.webrender.force-legacy-layers, gfx.webrender.software or something), but it is still less responsive than it used to be
Add to the fact that FF and TouchID don't work for our SSO provider for 2nd factor.
Both of these are making it tough for me to continue using FF for my daily driver (though I'd still use FF+uBO for personal browsing)
Obviously this could be configured with a group policy but our IT group isn't going out of its way for a non-preferred browser.
For the TouchID it's FIDO2 compliance - not sure if it's our SSO/MFA provider or FF but... it works fine with Chrome :/
Isn't this an implementation detail of how the kernel allocates memory?
I'm assuming jemalloc is maintaining some sort of cross thread allocation pool?
That doesn't mean that good locks don't need a good user-space component - they do - but it's only one side of the coin.
No, iPad is not affected.
https://github.com/WebKit/WebKit/blob/ae32cf14a9c1570e6ea8d2...
Which is, of course, a pretty bad thing, and an especially stupid thing to recommend, even with caveats! I expected a whole bunch of warning signs and even a "haha only kidding", but no, the author seems pretty gung-ho about this approach.
Apple is very happy to change and deprecate such things with no announcement. I don't know that anybody who'd follow such advice would also be careful enough to implement regression testing, and how reliable such testing can be!
Perhaps they can help pressure Apple to make such a useful lock function official.
Does any one have any suggestions for what addons to use with FF these days to make the web livable? It's been years since I was gone, and I want to do an apples-to-apples comparison to see how it fares.
Same. They also staunchly fight against introducing adblocking to the iOS version, with no justification given.
Sadly, the fight over on which browser engine the web runs is a done deal. Even if Manifest V3 sucks, it won’t lead to a mass exodus to Gecko. People will just switch their upstream to a Manifest V2 fork. Blink has become the Linux kernel of the web.
That said, I think Brave works better out-of-the-box from a privacy/security perspective. Hopefully FF can take some cues in terms of turning on some of this stuff by default (or at least having an onboarding that facilitates it)!
- uBlock Origin for general content blocking. Brave's filtering uses EasyList heavily so if those are enabled the results should be similar. Enable a social blocking list to match Brave's social blocking settings.
- CanvasBlocker can get you closer to Brave in anti-fingerprinting at the expense of performance. I don't personally keep it enabled for everyday browsing, but it's there if that's important to you.
- Auto Reader View to automatically enter reader mode like Brave SpeedReader. Difference is you have to enable it per site, which I prefer anyway.
- There are quite a few small Brave QoL features that aren't built in to Firefox, like protecting the ability to copy/paste in text fields and removing URL tracking parameters (Firefox removes some parameters but it's quite limited). For these I like StopTheMadness, which is actively maintained and works on Firefox, Chromium, and Safari. It is paid and Mac-only, however. On other platforms or to get the functionality for free just search the addon store for the stuff you want, for the most part the Firefox addon store has a lot less garbage than Chrome.
- IPFS Companion for IPFS.
- If you use Brave's Tor windows, just get Tor Browser which is Firefox-based and better configured for Tor.
- Firefox's new tab page might seem both barren (no background image or useful widgets) and spammy out of the box...first of all turn off sponsored links and all the Pocket stuff, then if it's too barren try out some extensions that replace the new tab page and see which one you like.I get that they're trying to free themselves from utter dependence on Google search revenue, but boy is this a spammy alternative... I used to leave the Pocket stories on, but now I will definitely be disabling them.
> So how do you use them? Well, it turns out they’re not documented. They rely on a non-public function and flags which I had to duplicate in Firefox.
Gotta love it. You need to reverse engineer the kernel to get good performance on MacOS.
People read through assembly to fix compiler issues, not to rationalize what the kernel is doing. You're right that this skill is still required for "perfect" optimization, but it's not really relevant when comparing kernels.
> // For information about the following undocumented flags and functions see
> // https://github.com/apple/darwin-xnu/blob/main/bsd/sys/ulock.... and
> // https://github.com/apple/darwin-libplatform/blob/main/privat...
Notably, Apple appears to not be updating the Darwin project the same way they once did, and the XNU kernel source code was last updated in mid-2021 (and pretty sparingly).
When I searched for os_unfair_lock_with_options, I didn't get any matches. Aside from some real-time Linuxy platforms where the kernel runs on top of a proprietary microkernel, you can find the source code for any Linux synchronization primitive.
So your complaint there seems misplaced
So, unless your target is Darwin, you can't be sure that the source is what your code is going to be interacting with. It's certainly a helpful starting point, but you do have to attempt to reverse engineer the interface to make sure you understand how it behaves.
So perhaps I am wrong. I was always under the impression that you couldn't count on Darwin to be representative of how iOS/OSX work anymore, but maybe I'm wrong.
I'm pretty sure there was some antitrust investigation over Microsoft doing the same thing: giving their own software an unfair advantage on their operating system due to the insights the Office team could gain from the kernel team.
Microsoft made a convincing argument that the relevant teams never talked to each other, and the Office developers just reverse-engineered undocumented Windows APIs, the same any other developer would have had to.
I'm gonna do a Stallman and post a reminder that webkit is an evolution of KDE's khtml. Not completely "done by apple" or even started by them.
Otherwise they would have closed it.
I worked on OS-Bypass HPC drivers for a pre-infiniband/ROCE NIC in the early/mid 2000s. About 90% of my time doing the driver was spent reading the kernel and IOKit sources, trying to figure out how I could use the highest performance interfaces possible in a stable way. For example, Apple really wanted you to use IOKit primitives (which used Mach IPC) to call functionality in your driver, but microbenchmarks showed it was about 50% higher latency than simple BSD ioctls from the BSD side of the kernel. That fit nicely with our driver model (which was split into OS-agnostic and OS specific code, and which used ioctls on every other *nix, and even on Windows), and got us slightly better performance.
Off topic, but has anyone noticed Firefox on iOS has gotten quite slow? It happens when I switch from another app to Firefox, and then tap the URL bar to highlight the text in preparation to type either a URL or a search query, the whole app will stop responding for anywhere from 1-5 seconds. This happens even on a fresh restart of the phone or after killing the app.
I'm using an iPhone 12 Mini on the latest iOS but I've noticed it for a few months now. It might sound minor but when everything else on the phone (including Safari) is so snappy, it's very noticeable.
To answer the GP's question, this does sound like a known Awesomebar issue that might be improved with a future update to the Places database: https://github.com/mozilla-mobile/firefox-ios/issues/11775
This is just a sign I should spend more time on HN and less on Reddit.
Nope. Sorry. It might actually be faster, but I haven't noticed anything over the last several months. I have FF/Mac/m1 open for hours per day, multiple tabs. Nothing jumped out from performance where it was noticeable.
Still, I applaud the effort to make Firefox faster on MacOS. I'm happy for every performance gain I can get, even if I don't notice it straight away. A few more minutes of battery life or a bit less fan noise can make such a difference.
This doesn't seem like it can be a real thing.
I have not checked the code. But I've worked with 3 ssl libraries and they all worked fine with non blocking file descriptors.
When I was adding SSL/TLS support to Gluster, I also worked with three libraries. NSS was tied with OpenSSL for the worst API, and was definitely the worst for performance. Maybe it doesn't matter when you never stress it, but I was stressing it so I could tell. Because of that experience I knew exactly what to look for, and was very unsurprised when I saw the familiar old symptoms. I even considered spending some time to fix it, but dealing with those super-hairy interfaces and crazy build systems etc. seemed like a poor fit for my first post-retirement project. I'll probably do some work on sshfs first, since it currently lacks a maintainer and is a better fit for me, then maybe I'll look into getting elbow deep in Firefox's "unique" codebase.