I've been shilling for Firefox for years. It is my primary browser for both development and personal use. But I still think it has some catching up to do with Chrome.
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.
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.
Is the profiler a new addition? I'm on Nightly and I recently noticed the appearance of its little speedometer button in my toolbar and I'd be interested to learn more about it. The graphs it generates look nifty, but I have no idea how to interpret them.
The profiler has been there for ages. It's definitely not new. They're moving where it's accessed but it's been under the Performance tab of the developer tools for a long time.
There are two different profilers. There was one in devtools for a long time that was aimed at web content. It was pretty nice for its time, but its time was a long time ago. In a separate project, a profiler for both content and browser UI was developed—that's the one at https://profiler.firefox.xn--comand-5g0c it has been seeing a ton of high quality work for quite a while now. At some point, it was clearly so much better that they started enabling it to optionally focus on web content (though platform stuff is still accessible if you need it). The recent change is the old devtools profiler has been put out to pasture and replaced with the newer one (with presets configured appropriately for web content), and additionally the platform profiler is more integrated so you don't need an add-on or anything; going to https://profiler.firefox.com gives you the option to activate the built-in functionality.
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.)
There is also a lot of catching up to do on Firefox iOS. It is still crashing on heavy and large websites (government websites in my country) and then the more I used it, the more it lags and taking down the whole iOS system.
Is there a public demo or test page for TinyMCE that reproduces the hangs? If not, you could use Firefox's built-in performance profiler to record a profile and file a Firefox bug.
I‘m on the other side of that. I'm constantly throwing large amounts of HTML at Firefox and it just goes on normally, literally 0 slowdown. Add some VueJS for additional fun. I deploy and get Chrome users complaining about performance. One example is that one can not add more than a few hundred options in an Options Select list in Chrome. You can throw literally 10'000 at Firefox. Similar stuff with text fields having 10'000s of rows.
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.
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?
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.
Advanced Custom Fields on WordPress allows for "click to initialize TinyMCE" on areas such as that which may be a usable workaround for now. Then you only have 1 initializing at a time,
I evaluated a few different options including Quill, but this problem never would have really come up in my prototypes. The performance issues really are only apparent when you have an obnoxious number of TinyMCE editors on a single page.
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.
Do you need to have them all active at once? One option could potentially be to enable instances on click and disable on blur or similar.
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.
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.
The plugin is technically just a management interface for functionality that is already in the browser. FF just doesn't surface it by default, because devs think it would scare casual users.
That's not the only reason. The other reason is that although it's pretty obvious to any one person how it should work, no two people's ideas are the same. Depending on how you are using containers, the answer to a number of questions can be completely opposite to someone else's usage. The theory was that Firefox would provide the underlying functionality, and specialized addons would specialize it to a style of usage.
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.
Honestly the implementation seems half baked, it's very hard to move sites to new containers, there is no list of sites with containers they belong to, etc. I don't know why you'd add a feature in the first place and then decide to hide it for vast majority of users instead of going the extra mile of making it user friendly and intuitive.
Probably because it's a bit of a difficult thing to explain to users in the first place. Instead, by providing just "primitives", they opened the doors to focused add-ons (like the one that isolates Facebook, effectively the first large-scale deployment that used it) without spending too much time on a feature that folks might have found difficult and might result in increased support issues. The status quo is that power-users can make it work, add-ons can use it if they wish, and the overwhelming majority of users can carry on happily ignoring its existence; not a terrible trade-off. But I agree that the management add-on could be better.
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.
I mean relative to the effort put into building this feature making the UI intuitive shouldn't be a huge task. Think when FF released "tabs" for the first, super intuitive and instant adoption. I wonder if FF is short on UI/UX contributors.
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.
You can also set a browser chooser as the default, and have choose which browser you want to open each link in. I’ve written my own, and it even lets me pick which chrome profile I want to open in.
I use Vinegar[1] on iOS and macOS. It renders YouTube using the native system video player, and strips all the cruft (up next, recommended, etc). It has the side effect of removing ads.
> Prevent YouTube from tracking your play/pause/seek activities.
(/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.
Personal experience: Battery drain was always my problem with Firefox on MacOs. Why when using Safari it is nice and full day surfing w/o recharge; but doing the same with Firefox would discharge laptops battery much faster.
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.
To no one's surprise, one has to use Apple's undocumented APIs to be able to match Safari's power use.
Odd that you’re being downvoted. If the article had shown that Safari or the system allocator used this locking strategy then that would be evidence, otherwise the person you responded to is just making things up
Battery life seems like an afterthought for anything other than Safari (and back when it was Trident-based, MS Edge on Windows), which is kinda weird when one considers how laptops have come to dominate computing.
I wish Mozilla had been able to keep pushing harder with their servo project. IIRC, one of the earliest upsides I remember hearing about to justify creating Rust (in order to build servo) was that the increased safety with regards to concurrency could allow a web renderer to parallelise computation across _underclocked_ cores, thereby setting a new benchmark for battery consumption.
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.
When I worked on Firefox for Android, we were constantly fighting for the broader Firefox org to take mobile more seriously —- if Gecko excelled on mobile with respect to power consumption, then a lot of that would spill over to desktop platforms “for free.”
Unfortunately nothing had improved by the time I left in 2021.
From my understanding, Chromium/WebKit/V8 and Firefox/Gecko/Spidermonkey are the last (major) contenders in the browser engine space. After Opera switched to WebKit in 2013. And Edge in 2020. I'm sure there are numerous lesser known ones...
* 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.
Google is dominating, pushing through Android, all Googles-Services and Microsoft Edge. A reason to worry because Google controls the Web and the Engine. Furthermore implementing an entire new engine seems an enormous effort. For instance Microsoft only allows usage of Microsoft Teams Web with a webbrowser based upon Blink. So were back in 2002?
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.
Google forked from WebKit in 2013, at this point there might be huge differences between WebKit and blink. Someone more knowledgeable might add something to this.
This. Firefox drains battery, but still less than Docker & a TypeScript dev environment. Using those three together means my M1 Air falls a LONG WAY SHORT of the 18hr battery life I was promised
I had to do a double take when I read the parent, but I suspect they were referring to running Linux to avoid the Virtual Machine overhead on MacOS. However I doubt the Linux driver support for the M1/M2 has anywhere near the level of power optimization as the MacOS drivers.
There isn't any other OS that you'd want to run as a daily driver on that hardware platform atm. Linux support is still immature/incomplete, and IIRC Windows support is completely absent. (Some of the people working on the Linuc port are also porting to some of the free Unices, too, which I assume are in a similarly incomplete state.)
If you think that persons battery life woes are bad, you should see how horrible my Windows/Ubuntu Intel work laptop is when running the same software.
I’ve been on brave for about 2 years now and all I see people talk about is Firefox. Should I swap? I thought people liked brave but I really don’t see it mentioned anymore.
Depends what you care about. I think there are two main reasons to use Firefox over Chrome:
- 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.
I use Brave and Firefox primarily on my Linux computers (and Safari on MacBook for battery reasons already mentioned). I just switch between them for different purposes. Usually Brave for Gmail or Google Docs, and Firefox if I need some extension not available in Brave (Firefox still seems to have more robust extension capability).
I have uBlock origin on brave so that’s moot, but I don’t use nextDNS. Is there a reason to use it when I’ve already got brave/uBlock killing most ads and trackers? (I also use proton VPN, not that it’s quite as relevant but figured I’d throw it out there).
We'll see what Brave can do to work around it, but chances are that content blockers are going to be handicapped when Manifest v3 is fully implemented.
Firefox will have no such problem, as Mozilla has specifically committed to keeping the necessary features.
Personally I still use NextDNS to help me kill ads on mobile, and also keep a tighter leash on my various IoT devices. You can block more than just ads with it and it also gives you interesting data, hard to beat for less than the price of a cup of coffee each month.
So I’m an usual user here - I’m tech savvy compared to most people (film/television background and just a general nerd) but I am a Luddite compared to y’all around here.
I imagine it’s not hard to set up, but what does it give me that ad guard + proton + brave (mobile) and proton + brave w/ uBlock origin (Mac) don’t?
Yeah its super easy to set up, but the biggest reason you would want to use it in addition to other adblocking stuff is that it works outside of browsers - you can block telemetry from your smart lights, you can stop a random app on your phone from showing you ads etc etc.
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.
Same situation. I switched to Brave a couple of years ago (from Firefox) and I occasionally check in on Firefox to see if I should switch back. I haven't seen a reason yet. Things like full screen support in YouTube sees a bit janky still. I like where Brave is going with getting rid of cookie consent and other annoyances without extensions.
Do you care about vertical tabs? (if not, you must not have many tabs open at once) If so, your choices are: Opera, Edge or Firefox with one of two extensions (I use Sidebery).
Thanks for that info! I think nested tab are lame as it wastes some of the tab title length. I use a browser window for each high level topic, which mimics the advantages of high level nests.
This is a fair point. In recent years (before Brave supported tabs, but after I left Firefox), I had to use a single window because the TST-style tab manager sat beside it in a separate window. This was annoying enough even with a single browser window, and it was unmanageable with multiple windows.
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!
Just to add another suggestion to the multiple windows approach: the Titler extension allows you to name each window so that the title shows up before the current tab name of that window. Unfortunately, Sidebery doesn't pick it up, which makes moving tabs between windows a bit of a pain...
I wonder whether this could be related to "profile bloat" or something.
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.
I may be mistaken, but I have found the Microsoft Edge to have done considerable catching up. In my Mac and on PC, it beats Chrome anyday in performance and ease of use. I understand that Microsoft have reasons to invest heavily on a modern, nimble browser. But do we have any other reasons - like trying to conquer a new market etc. Behind this?
* 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.
This blog post has some good discussion about what makes a good locking primitive. On macOS, os_unfair_lock is generally a good choice for many applications. That said,
> 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.
> leverage an existing relationship with Apple to ensure that it doesn’t become a liability in the future as the platform evolves
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.
With all due respect, you’re a small indie developer, and the situation is different when you make a browser used by millions of people. Apple does do whatever it wants, but sometimes it (wisely) realizes that what it wants is people to not be upset that people’s favorite app is broken in the next release of macOS, so occasionally steps are taken to ensure that doesn’t happen. This ranges from committing to SPI for longer than it is necessary for Apple’s own use, to putting in bundle ID or linked-on-or-after checks, or in rare cases reaching out to developers directly.
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.
> 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
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.
> 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.
I just got a message from a contributor to a popular macOS project I work on about this blog post and how it can help improve our performance, so I think you're mistaken.
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.
Happily, rather than using non-API OS internals, Firefox could recognize that their behaviour does not match normal applications and so they might have to actually implement spin locks themselves rather than relying on a API that is designed to support more general apps. That's what the other browser engines do, including webkit and that's an actual system library on macOS and iOS.
Those reasons are largely that the things that are perf critical for a browser engine don't match anything that normal apps do. That's the same reason gecko also isn't using the system allocator, as we see here.
You really don't want the rest of the OS making the performance trade offs people expect from browser engines these days.
Yes. Blink and WebKit, and I suspect a bunch of other - correct - software uses os_unfair_lock. Because os_unfair_lock is public, documented, and stable API.
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.
The solution here, rather than using OS-internals is for Firefox to implement spin locks themselves, which is the level that they should be thinking if they're making their own allocator. This is what webkit, chromium, etc - webkit even has a blog post: https://webkit.org/blog/6161/locking-in-webkit/
Correct, and that isn't what this article is talking about.
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.
> As an intermediate solution, I initially fell back to OSSpinLock on older systems. Later I managed to get rid of it for good by relying on os_unfair_lock plus manual spinning in user-space.
Have you looked at `__ulock_wake` versus `os_unfair_lock_with_options`? __ulock_wake is another private darwin API for locking.
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)
Post author here, `__ulock_wait2` is used under the hood by `os_unfair_lock()`. I considered it but it would have required more scaffolding, especially to support all the versions of macOS we care about. We might use it in the future though.
The go-to synchronization primitive on Windows, critical sections[1], does a short spin in then waits.
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.
It's so clear how Mac OS and Windows both can function without app stores that it's obvious that app stores are a rent-seeking middle men. Terrible that they've been normalized for mobile devices.
I don't see any issue with the app store models for macOS (mostly) and windows (could be useful, but not in its current implementation). They act as more curated package managers with a GUI, and an added bonus of taking care of payments (a hard problem!).
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.
These stores are not curated. They can catch the most egregious things, but they also are not really "safe" either. It would totally be worth 30% of my payment for a truly curated app store. However the Apple app store takes a lot of income for providing a negligible quality filter, updates, and taking payments (most payment processors take single digit percentages).
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)
The App Store on macOS is a convenient distribution channel. It’s helpful to have, especially because alternatives exist if it doesn’t have the right tradeoffs for you.
While I'm all for opening devices up the fact that app stores exist on platforms like Windows or Mac disproves the rent-seeking thesis if anything. Steam commands a 70/30 cut while software can be distributed freely on Windows which was in fact the normal situation on desktops before the advent of app stores.
App stores are distribution mechanisms and advertisement channels, same value proposition as Spotify compared to shipping your music on your own website.
Since side loading is a thing on macos this is a nonissue for the users, ios on the other hand... They're really only hampering adoption of the app store by placing ridiculous restrictions.
You can’t sideload NetworkExtension VPN apps on macOS, the entitlements for them to work are only distributed for App Store apps.
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.
> You can’t sideload NetworkExtension VPN apps on macOS, the entitlements for them to work are only distributed for App Store apps.
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.
Plausibly they could get around it by doing a dlsym() or something. In general it's not possible to prevent private APIs from being used if they underly public APIs, but perhaps if Firefox tried to evade the rules they could be sanctioned.
I think the day that Apple completely bans non-App Store apps is approaching very quickly. It became apparent when Mac OS started checking app signatures with a remote server a couple of OS releases ago and wouldn't let you open them in some cases even if you right click-opened. I wonder how many technical users will stay with Mac OS if Apple decided to go that route.
I have the VPN problem too. For me, it's a proxy thing. My company puts an HTTP proxy in-place inside of their VPN, and Firefox picks up the settings from MacOS.
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.
as someone with many tabs across many windows across many desktops/spaces, one weird trick i found is that when firefox starts up (on an intel MBP, 2019), it will churn CPU at over 100% until you go and foreground each of the windows in each of the workspaces. then the CPU usage becomes normal. perhaps it has to do with extensions like noscript or ublock origin, or my propensity to start firefox without internet access, but i don't think that matters here. not sure why this happens, but it's been required across at least the last few firefox restarts for me.
1 happens to me as well. And I even use the Mozilla VPN. I noticed it also happens with Cloudfare's Warp. Turning it on/off or even closing the display while they are active sometimes result in complete loss of connectivity when trying to interact with a tab again.
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.
> If you’re running Firefox on macOS you might have noticed that its responsiveness has improved significantly in version 103, especially if you’ve got a lot of tabs, or when your machine is busy running other applications at the same time.
Huh, now that you say it: I haven't been all that angry at Firefox lately.
I’m curious how it was determined that the locking was causing problems? Was it just some intuition from cases with poor performance and staring at code, or some perf-like tool (I don’t really know about the landscape of performance monitoring tools for MacOS) highlighting that a lot of time was spent in locks, or some known MacOS vs others difference?
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.
From the blog post it seems like the team was using OSSpinLock, which was deprecated (for good reason) and then when trying to use the replacement (os_unfair_lock) degraded performance on some tests. I don’t have details on how they determined what the issues were but considering if the results were across a single change and one had access to the source it doesn’t seem all that difficult to see why there are performance differences. The various profiling tools on macOS (Instruments, mostly) would help confirm this.
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’m also weakly curious why jemalloc needs so much locking anyway?
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.
I guess you mean wrapping very small sections of the program with timing code and making sure the cpu executes the timing instructions in the right order. Maybe that works but it sounds like choosing between poor accuracy and massive overhead. On Linux on x86 you can use perf to get access to model-specific registers on the cpu for a large number of performance counters (from cache hit counts to branch prediction misses to all kinds of crazy things). I’m not aware of an equivalent to perf on macOS and I’m not sure the kernel provides appropriate apis. Maybe instruments is it but I’m not sure that it can give access to those counters (they surely exist on the M1 cpus) or that it can be run in a non-interactive way.
I have been using FIrefox as my main browser on Mac for a couple of months now (again) and it really does feel like they've done a lot of performance enhancing under the hood.
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).
Hey, would you mind posting some tips (or an article/link) describing how you stripped the bloat from your Firefox config?
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 use these settings to clear all visual clutter. Basically looks like Librewolf then. For privacy related settings I check Arkenfox user.js and add the ones I find useful and don't cause breakage manually (but going thoroughly through settings already does most of it).
In a more perfect world, all of your "Remove *" items would be implemented as extensions that come pre-installed, and this process would be as simple as opening the Add-ons Manager on a new install, doing a Select All, then hitting Delete.
Out of curiosity, why are people so concerned about Pocket?
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.
My main problem with Pocket is that when Mozilla acquired them in 2017, Mozilla promised to open source the Pocket back-end. That was a big fat lie, and they've never even owned up to it.
I don't have a problem with Pocket qua Pocket. I didn't even have an issue with the "recommended stories" that rolled out years ago. But when I just tried FF I was appalled by the spammy "stories" all over the recommended stories section.
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.
My experience is that poor performance esp. memory use is often caused by bugs, and you can't predict the presence of bugs based on whether or not you think a feature is "bloat". Though you can simplify the UI I suppose.
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.
I agree with most of what you said, except that you can't remap CMD+P and a few other keys used by FF itself whereas on Chrome you can. I made a patch to my FF to make this possible.
I'm using Firefox on Windows 11 and it's noticeably clunkier than Chrome, especially when using heavy web apps like Jupyter Lab. Oftentimes the browser hangs completely, including all its windows, for 10-30 seconds at a time.
This has been my experience over the years every time I've attempted to switch back from Chrome to Firefox.
To quote some relevant comments on other threads here:
> 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.
I love the FF profiler. However I can't use it when the entire browser is hanging. I would need to run an external profiler on the browser itself. I will file a ticket as soon as I have any useful info... but when it's an intermittent 30-second freeze on all browser windows, it's tough to get any data on it.
you just know someone at apple is having a terrible day now that they realized they'll have to support their weird hack for hybrid spinlocks forever now that firefox adopted it
I'd actually bet nobody at apple cares if they break Firefox users, they don't have the backwards compatibility culture of some companies like microsoft, especially for undocumented apis.
Don’t, you’ll lose your money. Firefox is popular enough to be on their list of apps they try not to break. And the culture you’re talking about does exist, they’re just less insane (and chatty) about it.
For a while now, performance has not been an issue for me to not use Firefox. It's the no support for the multiline tabs and/or tab groups. Both features which were previously possible in Firefox. This is pretty much a blocker for me and they don't seem to have any plan to fix this.
Are there reasons that the "Simple Tab Groups" extension isn't suitable for you? It seems to be well-maintained, cleverly uses Firefox's "hide tabs" API to keep a single window behind-the-scenes, and has integration with lots of other features like Firefox's containers. I think it's an indirect descendent of the old Tab Groups extension when it was spun out of Firefox.
It doesn't scale. Also we intuitively identify a tab by its location in our browser. Opening a different window and then locating that tab there is slow.
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.
After few dozen tabs the tab width becomes so small that it is difficult to click on them or figure out which tab is which. Multiline helps in maintaining the tab width.
Has the battery life issue improved with Firefox at all in the last year or two? I had to choose between degoogled-chromium and Safari because videos drained my battery so fast on my Macbook.
Yeah, video on Firefox is so much worse than any other browser it's insane. Safari still has weird issues with pitch shifting videos playing at over 1x (1, it's an issue with webkit, as it affects Orion as well,) which makes it unviable for me as well. So I'm stuck with... Brave, despite having issues with it too.
Even if the battery life is not that good as with Safari, there's nothing like Multi-Account Containers extension on other browsers. Helps a lot with separating accounts with added conveniences. Can't really go back to any other browser after having used containers on Firefox!
I have been a very happy Firefox user for several years but recently (with 104) I noticed how it uses massive amounts of CPU when being idle. About 60-120% CPU are not uncommon. In the task manager there is no task with heavy CPU load. It seems to get somewhat better over time, but it is really significant, making my Macs quite loud with just an idle Firefox.
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.
The trick to using Firefox on mac like 5 years ago was to use the developer edition. For some reason it was way faster than standard Firefox. I don't know if that's still the case, but I stick to it for good luck.
For a few years, DevEdition had multiple content processes enabled (codename "electrolysis", aka e10s), while it was still off in release builds. That made a huge, huge difference to responsiveness and resilience.
Great to hear that Firefox on macOS might get snappier with these changes. The reliance on undocumented APIs is the only potential red flag.
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?
I've recently switched from Firefox to Orion.
Ideologically, I'm Firefox all the way - But even in beta, Orion is such a better browser.
* Vertical tabs
* Support for most of the extensions I need
* Much better battery life (at least 1hr+ extra on my 14" M1 Pro MBP)
* Better RAM usage
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
> 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.
I think you're misunderstanding the context and the way the allocator works. Take a look at the docs/papers on JEMalloc in general to get a sense of it, but it's already doing what you describe (this would be the threads cache that you can tune). This reduces the need for locking in exchange for less memory efficiency; what this post is talking about is efforts to improve the efficiency of the remaining synchronization.
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.
You can see the relevant code from the links. It's all in memory/build/Mutex.h. On windows it uses critical sections and on non-Darwin systems it uses pthread mutexes.
I've noticed pretty obvious performance improvements in Google Maps recently on macOS (with original M1 chip). Zooming and panning is much more responsive, akin to using Maps on Google Chrome. I wonder if this could have contributed?
This has the whiff of someone discovering the basics of high-performance locking. For e.g. other long-standing mutex implementations have spin/pause,sleep strategies. See Go's mutex, absl::Mutex, and others.
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.
> 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.
Here's a previous HN discussion about that (in particular Skylake CPUs greatly diverging from previous behaviour):
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.
I think you misunderstand the author's context. They are well of the various spin/pause/sleep strategies, and they have a specific one they need to apply to their allocator. They're just changing what OS interface to one that better matches the desired behaviour. While they are writing the article for readers who might not be as familiar with these issues, so they're doing a lot of explaining, the actual work they did, particularly exploring the semantics of os_unfair_lock_with_options (as opposed to os_unfair_lock), would potentially be informative to authors of those libraries (though likely not useful as they'd no doubt have requirements not to use private APIs that might keep an application from being made available in Apple's App Store).
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.
> This has the whiff of someone discovering the basics of high-performance locking.
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.
Many high performance locks do not, fundamentally, need to allocate memory. If they do, it is often for:
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.
That doesn't strike me as much of a constraint. TCMalloc's transfer cache and global page heap are protected by Abseil locks and this doesn't seem to have caused a circular dependency crisis.
Guys, please, please make copy-paste in Firefox reliable on macOS. That's worth much more to me than more performance, because I find the performance quite good already! It's so frustrating to CUT (or copy) something in Firefox and then paste only to find the previous data still on the clipboard. It's been like this for ten years now, and it's still broken a good 20% of the time. It's only Firefox that I have this problem in, and it happens irrespective of profile or machine (I have many).
I’d love for it to be seamless to switch between browsers. For that, I’d want a common history, bookmarks, cookie store, open windows/tabs, and most importantly, use of the system keychain (on macOS). I’ve never seen anyone talk about trying to effectively sync with a preferred/primary browser. Why isn’t this the goal? Especially for Firefox who’s trying to get people to switch; make it easy! Import isn’t enough, and it still doesn’t use the system keychain.
Looks like this might finally make Firefox not use at least 30% of CPU at all times, which meant that with Firefox running my 2020 Intel 13" had really terrible battery life and was always just a little bit of extra load away from annoying fan noise. Chrome/Brave never had any such issue even with hundreds of tabs so I don't think it's my particular choice of websites or the like. Will try the new version once I find time, I really hope it'll do the trick.
> its responsiveness has improved significantly in version 103, especially if you’ve got a lot of tabs
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.
I wish they would make it more responsive for X11 forwarding
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
I absolutely love FF but the cookie prevention is breaking some of my internal sites (not just for me but coworkers who I don't control which browser they use).
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)
Assuming you are talking about tracking protection, you can turn that off on a per site basis by clicking on the shield symbol on the url bar while you are on the website that is breaking, and clicking the slider next to the "enhanced tracking protection is on" text. Unfortunately I don't know anything about how TouchID interacts with Firefox.
It's very concerning that Firefox, a major browser used by millions, relies on undocumented Apple APIs. While it's brilliant to discover this gem in kernel space to use it "in production" is a whole different story. I wonder if there are unknown system-wide negative consequences by using this new lock method.
Kernels allocate memory and hand pages back. Allocators in userspace have the job of carving these up for application use, and must do so across multiple threads, necessitating locking or similar primitives.
My understanding was that allocators nowadays have cache pools per cpu or thread and only rarely need to lock on global state (when imbalances between pool sizes
necessitate shifting resources around).
They do and so does jemalloc in Firefox, however that lowers contention, it doesn't let you do away with synchronization. Consider this simple scenario: a thread allocates a chunk of memory from its per-thread pool, but the object is later released by another thread. You can't do that w/o synchronization around the pool. Per-CPU pools are even trickier because a thread might be moved around between different CPUs by the scheduler while it's allocating memory. So you need special facilities to implement those in user-space like restartable sequences: https://lwn.net/Articles/650333/
Just curious, when developing a cross-platform application such as FF, would it make sense to implement an efficient lock within the FF codebase rather than relying on undocumented OS functions?
In a word: no. Efficient locks can only be implemented with significant involvement from the kernel. The best locks that can be implemented entirely in user-space will still suffer from the problems described in the article. Locks have complex interactions with scheduling and the only place where informed decisions can be made about them is within the kernel.
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 specific hardware support is needed to implement a lock. The atomic operations are all accessible from user-space - they are platform dependent though. The problem with locks is that they interact with scheduling and that's where the kernel comes in, that's why you need an OS-specific component too.
I really hope it reverts back to the old documented approach if the new API breaks things, because I can the see the day that Apple pushes an update to remove this API without any prior notice.
Sorry to say this, it still sucks on mac.
For ex: If I press `click to go back` it still shows the same page, if I click again it will directly jump to last but one page.
I know that issue, it happens when I use a Google site like YouTube where they decided to break the browser UI's functionality and badly implement it themselves. So the back button sometimes doesn't work when the site's JS encounters a bug, you can't stop loading because YT does everything without reloading the page etc.
TL;DR: Firefox switched to an undocumented kernel lock function and flags.
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.
After decades of using FF and its progenitors, I switched to Brave a couple years ago for performance reasons. As much as I like the experience (especially now that vertical tabs are rolling out), I'd rather support a non-Chromium browser like FF. (I've been playing with Orion for the same reason, and it also seems great.)
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.
I use these Firefox extensions which provide certain features that are built in on Brave:
- 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.
Thanks, this is super helpful. I do have to agree with the spamminess of the Pocket-sponsored ads on new tabs. Last time I used FF I didn't mind the Pocket stories section, but when I opened up today it was half-full of credit card offers and other undeniable spam (unlike sponsored news stories that I remember from before).
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.
I use a combination of strict FF settings, https-only, disabled suggestions, disabled autoplay, DDG search by default plus several keyword searches. Extension-wise only uBlock Origin and multi-account containers. That’s it. The web is very livable, no ads anywhere, the vast majority of tracking is gone, the browser is fast and responsive.
Is Privacy Badger still needed in 2022? My impression was that uBlock Origin updates filters often enough, and so Badger's heuristics don't give it an advantage anymore.
I don't know the answer to your question but I would agree with you. I used to be all for Chrome but with Manifest V3 it's clear Google has too much influence and we need to either switch to Firefox or create a fork of Chromium that is developed entirely separately
Bingo. I forgot to mention my company has two Chrome extensions, which we are now in the throes of updating. That definitely soured my mood, and increased my interest in getting off the Chromium train (even though I understand Brave plans to continue supporting V2 extensions indefinitely).
> I switched to Brave a couple years ago for performance reasons.
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.
I'm not convinced about Blink having won. Webkit is a significant factor which seems to be making it harder for Google to drag standards wherever they want, and Firefox still _works_ in 99% of cases (i.e. black swan could cause easily public perception shift, and there's an alternative right there).
I agree that this is what makes FF such a great alternative. If I tell my mom to use Brave instead of Chrome, she'll wonder what it is. If I say to use FF, she'll remember it from years/decades past and have no problem.
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)!
> However, as I dug into Apple’s libraries and kernel, I noticed that some spin locks were indeed available, and they did the spinning in kernel-space where they could make a more informed choice with regards to load and scheduling. Those would have been an excellent choice for our use-case.
> 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.
At some level of performance demand, you need to reverse-engineer (or read the source code of, if available) the kernel to get good performance on any OS.
Unfortunately, when it comes to performance, the devil is in the details, so even the possibility of stuff that isn't in Darwin means you're doing some reverse engineering.
No, it's not true across OSes. Some OSes are fully open source, and some OSes don't provide their source code. There are OSes like MacOS where the core bits have been open sourced to varying degrees over time.
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.
It's unsupported though. As you mentioned, minor version releases and security patches certainly don't get updated in it. I couldn't find os_unfair_lock_with_options in it (maybe I just missed it). AFAIK the only reason you can still build from the source is because of the work from volunteers.
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 slipped a note about the source code in... But on further reflection, I suspect for the best performance some reverse-engineering will still be needed even if all components are open (does the source code really tell you what assembly is generated? Does the assembly really tell you how the CPU will execute it?)
When was the last time you needed to read assembly code to debug a kernel-level issue in FOSS software? There's a lot of software you can use to profile the entire kernel and userspace[0], or explore the stack trace[1] of your software. If you're not using those and instead debugging your software by counting SIMD calls in the Ghidra editor, you're wasting an unconscionable amount of time.
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.
There's a big difference between studying the API and not having an API. It's ridiculous that you have to call an unexported symbol for something as basic and fast locking.
Some research borders on reverse-engineering. I know I've had to dig into the source of Wayland and X11 to do anything related to them. Sure, there's an "API". The API is the source code.
That's always been true on MacOS, especially if you care about performance, are doing something weird, or both.
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.
> done by apple, with access to their internal documentation
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.
It's funny because in the 1,990s this was cause for the whole government to go after Microsoft and talk about forcibly breaking their browser division away from their OS division.
That may be true. It's also using an open source browser engine, isn't being used to embrace/enhance/extinguish web features, and isn't built deeply into the market dominant OS by a company already found to be using other anticompetitive practices. Don't get me wrong, I'm not nominating Apple for sainthood. They're far from the territory Microsoft was treading at the time.
This is good to hear, I'm looking forward to trying it out.
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.
I'm fine with calling Blink based browsers "Chrome skins" and WebKit based browsers "Safari skins" but only if we all understand that "skin" isn't just a cosmetic thing. Firefox on iOS has its own features, settings, history, bookmarks, sync system, and other stuff that can create real, noticeable differences. Even if you assume "skin" means just the UI behavior, wouldn't it make sense that there could be a Firefox-specific bug with the URL bar?
This sounds exactly like my issue (and I have even experienced it with the exact site in the bug report, reddit). For some reason I did not even think that the firefox iOS app would have an open source bug tracker but of course it would. Also had no idea it was called the 'awesome bar'.
This is just a sign I should spend more time on HN and less on Reddit.
Yup - have noticed this. Just in the past week or maybe 2. Safari doesn't exhibit the issue so it seems to be with the wrapper - & definitely related to addressbar/URL typing/homepage functionality freezing the app. Quite a few crashes too which I've never seen before.
For me, FF has a killer feature: tree-style tabs (extension). Does Brave plan to add such a feature?
(When FF suddenly decides to eat too much CPU, what helps us to open a tab with about:performance. Just the act of doing so seems to kick some misbehaving thread, and the CPU consumption goes down to normal amounts. I hope somebody at Mozilla is working on fixing that.)
I want to like Firefox and ditch Chromium just because of this whole MV3 kerfuffle but it's not like Firefox is any better. Besides, Firefox has unilaterally killed off useful features like PWAs in the recent past. It's too flawed a product to be hyped up like this.
> If you’re running Firefox on macOS you might have noticed that its responsiveness has improved significantly in version 103, especially if you’ve got a lot of tabs, or when your machine is busy running other applications at the same time.
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.
Sadly, I agree, don't think I noticed anything special when this happened. I'm on older hardware though; MBP 2014, i5 2.6GHz, 16GB DDR3.
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.
When I tried going back to Firefox (for about the tenth time) recently, I was able to determine that the main reason for the lack of responsiveness was their awful not-very-concurrent TLS library. Things would tend to stall in all tabs when one tab was setting up a connection to fetch some resource or other. If you think about how many resources are on a typical page nowadays, it's easy to see how this leads to near-constant stalls. IMO they could fix a lot of their responsiveness problems by transitioning to a better performing (and BTW more standard) TLS library.
Some things are more visible via runtime observation than via code inspection, plus I have prior experience coding with NSS and trying to work around its performance shortcomings. I'll bet neither you nor any of the downvoters have checked the code either, or worked with NSS, or even remembered prior cases where NSS was responsible for major slowdowns. Some people just don't like to see criticism of their favorites, and lash out kind of mindlessly. I have no interest in trying to engage with people who bring nothing but denial to the table.
Was one of those NSS? "Worked fine" doesn't necessarily mean that it performs well, especially under contention. It's absolutely trivial to write code that will happily consume non-blocking descriptors, or nominally provide them, while still blocking all over the place behind the scenes. Most often this happens because all real work is shoved to separate worker threads, like Linux AIO did for a long time, but there are other ways it can happen too.
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.
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.