[HN Gopher] Improving Firefox Responsiveness on macOS
___________________________________________________________________
Improving Firefox Responsiveness on macOS
Author : Amorymeltzer
Score : 514 points
Date : 2022-10-10 15:19 UTC (7 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| Jarred wrote:
| 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/d4061fb0260b3ed4861473
| 41b72468f836ed6c8f#diff-08f993cc40af475663274687b7c326cc6c3031e0d
| b3ac8de7b24624610616be6 // // 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)
| gsvelto wrote:
| 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.
| cbsmith wrote:
| Per the documentation (https://github.com/apple/darwin-
| xnu/blob/main/bsd/kern/sys_u...), it looks like ulock_wait
| might be one of the XNU primitives that supports
| os_unfair_lock.
| jupp0r wrote:
| Why does jemalloc need to lock in userspace in order to allocate
| memory?
|
| 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?
| saagarjha wrote:
| 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.
| mcovalt wrote:
| Note that the version of Firefox this article references was
| released on July 26, 2022.
| seba_dos1 wrote:
| I remember reading this article around that time too. Not sure
| why it shows as released today (or am I having a deja vu?).
|
| [edit] Could be this Twitter thread that I have in mind:
| https://twitter.com/gabrielesvelto/status/155808346105915392...
| saagarjha wrote:
| 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.
| lapcat wrote:
| > 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.
| cnagesh wrote:
| 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.
| ubercow13 wrote:
| Oh! Safari does that for me too, since forever.
| strager wrote:
| This happens for me with YouTube in Safari occasionally. It
| might be a bug with the website, not Firefox or Safari.
| alpaca128 wrote:
| 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.
| gnicholas wrote:
| 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.
| resfirestar wrote:
| 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.
| gnicholas wrote:
| 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.
| hey2022 wrote:
| 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.
| e40 wrote:
| I add Privacy Badger to that.
| hey2022 wrote:
| 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.
| nsgi wrote:
| 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
| gnicholas wrote:
| 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).
| [deleted]
| jorvi wrote:
| > 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.
| wryun wrote:
| 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).
| gnicholas wrote:
| 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)!
| behnamoh wrote:
| I use Brave on iOS too and it blocks YouTube ads :)
| pagade wrote:
| 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.
| andrewia wrote:
| 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.
|
| https://github.com/drive4ik/simple-tab-groups
| viraptor wrote:
| Tree style tabs (https://addons.mozilla.org/en-
| US/firefox/addon/tree-style-ta...) work just fine. You get the
| grouping there.
| pagade wrote:
| I have pretty much used all possible Firefox addons for this.
|
| No it is not fine. Using vertical tab navigation was painful
| and slowed me down.
| gjm11 wrote:
| What browser do you use instead that does support those?
| pagade wrote:
| Used following work around for few years:
| https://wrw.is/multiple-tab-rows-in-firefox/
|
| 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.
| disadvantage wrote:
| > 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.
| ghostpepper wrote:
| 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.
| [deleted]
| lucideer wrote:
| 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.
| pca006132 wrote:
| I thought firefox on iOS is just Safari with another skin.
| resfirestar wrote:
| 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?
|
| 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
| jonas21 wrote:
| The browser engine is the same, but all of the UI surrounding
| it is provided by the app, so they could have done something
| that caused a slowdown.
| dochtman wrote:
| It is.
| jeffbee wrote:
| 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.
| FartyMcFarter wrote:
| > 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):
|
| https://news.ycombinator.com/item?id=17336853
|
| Original link:
|
| https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpu...
| jeffbee wrote:
| That is good info!
|
| 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.
| rockdoe wrote:
| The problem is that these are the locks in the _memory
| allocator_ , so _they cannot allocate any memory_.
|
| Most high performance implementations don't need to operate
| under that limitation.
| jeffbee wrote:
| 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.
| cbsmith wrote:
| 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.
| BeeOnRope wrote:
| > 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.
| bgro wrote:
| 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.
| callahad wrote:
| 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.
| wafriedemann wrote:
| 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).
| astrange wrote:
| 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.
| wafriedemann wrote:
| Always helpful to know how to go into troubleshoot mode.
| eshack94 wrote:
| 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.
| cptskippy wrote:
| No the OP, but for me the only bloat is Pocket. I also
| disable DoH but that isn't really bloat.
| ellm wrote:
| 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.
| [deleted]
| cptskippy wrote:
| I just don't need it. Firefox Sync allows you to sync
| bookmarks and pull open tabs from other systems.
| mort96 wrote:
| 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.
| eshack94 wrote:
| Thanks for the info!
| wafriedemann wrote:
| 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).
|
| 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
| cxr wrote:
| 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.
| eshack94 wrote:
| Thank you very much. This is quite useful and I appreciate
| the time and information.
| romseb wrote:
| If you start fresh, https://ffprofile.com makes it easy to
| create a profile file without the bloat.
| webmobdev wrote:
| Tor Browser (without Tor) is Firefox with most of the crap
| removed.
| [deleted]
| notacoward wrote:
| 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.
| LtWorf wrote:
| Did you investigate the code?
|
| This doesn't seem like it can be a real thing.
| notacoward wrote:
| 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.
| LtWorf wrote:
| Ok so no.
|
| I have not checked the code. But I've worked with 3 ssl
| libraries and they all worked fine with non blocking file
| descriptors.
| notacoward wrote:
| 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.
| r00fus wrote:
| 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)
| genrilz wrote:
| 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.
| r00fus wrote:
| The issue for per-site disabling is that the default is "on"
| and many sites simply fail to work (silently) when they
| aren't allowed 3rd party cookies.
|
| 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 :/
| wryun wrote:
| Can't you just turn off the cookie protection for all sites and
| keep using Firefox (well, not for TouchID...)? Security,
| custom, ...
| AceJohnny2 wrote:
| 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.
| whoisthemachine wrote:
| 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?
| gsvelto wrote:
| 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.
| joeldo wrote:
| My understanding is that an efficient lock would require
| hardware support, which is surfaced by the OS.
| gsvelto wrote:
| 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.
| _ph_ wrote:
| 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.
| magicalhippo wrote:
| Similar on Windows FWIW. It could be using a full core or more,
| but FF task manager shows barely any activity.
|
| Not always, but often.
| viraptor wrote:
| Have you reported the bug? If not, please do. Things won't get
| fixed without people actually helping with the experience.
| Fidgeting0026 wrote:
| 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.
| ziml77 wrote:
| Issue is still there. I tried using it again a few weeks ago
| and it had significantly higher power usage on my M1 MBP than
| Chromium browsers.
| btdmaster wrote:
| Have you tried H264 video? https://addons.mozilla.org/en-
| US/firefox/addon/h264ify/
|
| (I was reading
| https://bugzilla.mozilla.org/show_bug.cgi?id=1736878, which
| suggested VP9 is not yet there.)
| d3nj4l wrote:
| 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.
|
| Sigh.
|
| 1: https://orionfeedback.org/d/149-poor-audio-quality-when-
| play...
| boarush wrote:
| 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!
| gizmo wrote:
| On m2 MBA firefox battery life is fantastic
| aliqot wrote:
| It's not m1 with safari fantastic. Safari's bland though, so
| compromises get made.
| smoldesu wrote:
| If only Apple hadn't pulled a Google on us and let people
| use uBlock Origin in Safari unimpeded...
| chaxor wrote:
| Man, why is everyone so obsessed with uBO? It's fine, but
| not sufficient IMO - uMatrix is _worlds_ better.
| TylerE wrote:
| Some of us don't like 80% of the web being broken by
| default.
| smoldesu wrote:
| They're both great, but it's kinda irrelevant if they're
| both broken.
| Fidgeting0026 wrote:
| What's better about uMatrix?
| nsomaru wrote:
| And no longer being maintained, so there's that
| erichurkman wrote:
| Do you mean uBlock Origin is no longer being maintained?
|
| https://github.com/gorhill/uBlock/releases shows many
| recent releases?
| reciprocity wrote:
| Parent comment is referring to uMatrix which is no longer
| maintained and last updated 20 July 2021.
| viraptor wrote:
| Until I see ads when using uBO, I don't have a reason to
| change. And I don't see ads.
| gnicholas wrote:
| Is this with lots of tabs open, or just in general?
| kishansh wrote:
| When will firefox backend become a complete rust codebase ?
| CrankyBear wrote:
| Switch to Chrome.
| Melatonic wrote:
| Always cracked me up that the browser named "Chrome" had a logo
| that was literally a super colourful circle with nothing chrome
| about it
| chaxor wrote:
| Ew
| flutas wrote:
| > Switch to Chrome.
|
| Support a less centralized internet.
|
| Switch to any browser that isn't chrome or chromium based.
| theodric wrote:
| 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).
| quesera wrote:
| Weird. I've never had this problem.
|
| 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?
| kiwijamo wrote:
| I use Firefox on Mac and can't say I've seen this behavior.
| Sirened wrote:
| 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
| TillE wrote:
| That's definitely not how Apple works. They'll just break it if
| they want to, though the change would probably show up in a
| beta OS first.
| saagarjha wrote:
| Apple would only break this if there was significant benefit
| to them for doing so.
| cbsmith wrote:
| You might be confusing a feature for a bug. ;-)
| mattnewton wrote:
| 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.
| saagarjha wrote:
| 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.
| AceJohnny2 wrote:
| If you use an _undocumented API_ and it breaks, Apple will
| point at you and laugh.
|
| Especially if you're an org with the pedigree of Mozilla.
| meisel wrote:
| How does chrome deal with this in whatever allocator they use?
| shadowgovt wrote:
| See in the article where the author says
|
| > 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.
| cbsmith wrote:
| 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.
| jeffbee wrote:
| It's designed to avoid contention. The allocator mutex is tuned
| for fastest uncontended acquire and release.
| rockdoe wrote:
| Seems like it actually works similarly to the "old compatible
| path" described in the article:
| https://news.ycombinator.com/item?id=33153080
| cbsmith wrote:
| I think, without exception, thread safe allocators all try to
| avoid contention.
|
| Under the covers Chrome uses futex on Linux, SRWlock on
| Windows and os_unfair_lock (not _with_options) on MacOS.
| ccouzens wrote:
| And how does Firefox deal with it on other platforms? (Windows,
| desktop Linux, Android Linux)
| cbsmith wrote:
| 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.
| jhatax wrote:
| 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?
| l1n wrote:
| looks like they just use system malloc:
| https://chromium.googlesource.com/chromium/src/base/+/master...
| garaetjjte wrote:
| This document is outdated, PartitionAlloc is used for all
| allocations now: https://chromium.googlesource.com/chromium/s
| rc/+/ec6b52f91a4...
|
| It uses plain os_unfair_lock: https://chromium.googlesource.c
| om/chromium/src.git/+/refs/he...
|
| EDIT: It also combines os_unfair_lock with manual PAUSE
| spinning.
| dahfizz wrote:
| > 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.
| shadowgovt wrote:
| 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.
| fsflover wrote:
| Except, you know, on a FLOSS OS.
| lapcat wrote:
| There's quite a bit of macOS that's open source. The author
| links to source code in Firefox, and that source code has
| links to Apple's source code:
|
| > // 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...
| cbsmith wrote:
| 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.
| saagarjha wrote:
| This, as mentioned above, is true across OSes.
| cbsmith wrote:
| 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.
| dagmx wrote:
| Mid 2021 lines up with the last major release of
| macOS...updates to the OSS repo happen after each major
| release. macOS Ventura has yet to release.
|
| So your complaint there seems misplaced
| cbsmith wrote:
| 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.
| saagarjha wrote:
| Last commit was earlier this year for a Monterey release:
| https://github.com/apple-oss-distributions/xnu. The next
| one will almost certainly be for the first build of
| Ventura. Here is the header for the (private) function
| os_unfair_lock_lock_with_options:
| https://github.com/apple-oss-
| distributions/libplatform/blob/.... Synchronization
| primitives happen to be one of the things Apple is pretty
| good about releasing the source to.
| shadowgovt wrote:
| 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?)
| smoldesu wrote:
| 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.
|
| [0] http://www.sysprof.com/
|
| [1] https://github.com/brendangregg/FlameGraph
| saagarjha wrote:
| It's often useful when confirming what code made it into
| the kernel you're testing.
| phendrenad2 wrote:
| You're definitely not writing performant BSD/Linux code
| without closely studying the API, and reading the manpages
| won't be sufficient.
| dahfizz wrote:
| 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.
| lilyball wrote:
| The code comment links to Apple Darwin GitHub repos. It sounds
| like "undocumented" means "not in the SDK", rather than
| requiring reverse-engineering.
| drewg123 wrote:
| 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.
| [deleted]
| nsgi wrote:
| I wonder what the Chromium team did
| LtWorf wrote:
| clone webkit, done by apple, with access to their internal
| documentation
| wongarsu wrote:
| > 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.
| tick_tock_tick wrote:
| Yes but Apple also sells the hardware so that makes it
| legal (for some reason I still don't understand).
| Melatonic wrote:
| Google also pays Apple and ungodly amount to make Google
| the default search engine - who knows what they have
| going on behind the scenes.
| LtWorf wrote:
| I remember there was a comic strip that apple and google
| get away with stuff because they don't have an S in the
| name, like micro$oft.
| saagarjha wrote:
| Google has thrown out most of the code that this would be
| relevant for.
| phendrenad2 wrote:
| 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.
| cestith wrote:
| IE was far from using a single undocumented API call.
| jaywalk wrote:
| I think it's safe to assume that Safari is also far from
| using a single undocumented API call.
| cestith wrote:
| 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.
| runlevel1 wrote:
| I tried Firefox again a few days ago, and it was indeed
| noticeably snappier. In fact, it felt snappier than Chrome on the
| handful of sites I tried.
|
| 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.
| Melatonic wrote:
| It has been snappier for me for awhile now on Windows at least.
| I have not used it on OSX enough to really know but I never
| found it slow
| BolexNOLA wrote:
| 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.
| Melatonic wrote:
| I would recommend it. Firefox + uBlock Origin + NextDNS is an
| awesome experience. I keep NoScript mostly off but
| occasionally enable.
| BolexNOLA wrote:
| 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).
| donatzsky wrote:
| 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.
| BolexNOLA wrote:
| Appreciate the insight!
| synicalx wrote:
| 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.
| BolexNOLA wrote:
| 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?
| synicalx wrote:
| 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.
| mr_toad wrote:
| > I've been on brave for about 2 years now and all I see
| people talk about is Firefox. Should I swap?
|
| They're not wives, you can have more than one.
| plonk wrote:
| I have news about some people's approach to wives.
| BolexNOLA wrote:
| It's far more conducive for the way I work to stick to one
| browser for the most part. You do you.
| james_pm wrote:
| 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.
| donatzsky wrote:
| > I like where Brave is going with getting rid of cookie
| consent and other annoyances without extensions.
|
| Firefox is supposed to get that too. Believe it's in
| Nightly already.
| wryun wrote:
| 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.
| SkyMarshal wrote:
| 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).
| babypuncher wrote:
| 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.
| gsvelto wrote:
| 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.
| babypuncher wrote:
| I'll try to get on that this week sometime
| skybrian wrote:
| Have you looked at ProseMirror and Quill? I'm wondering how
| they compare.
| babypuncher wrote:
| 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.
| [deleted]
| cpeterso wrote:
| 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.
|
| Here are instructions of using the profiler with just a few
| clicks: https://profiler.firefox.com/
| ryall wrote:
| For me, having to log in to multiple AWS accounts, Firefox
| containers are a killer feature
| synicalx wrote:
| Depending how those accounts are set up and related to one
| another, you may also get some mileage out of this add-on -
| https://addons.mozilla.org/en-US/firefox/addon/aws-extend-
| sw...
|
| Basically it just lets you extend how many roles/accounts you
| can switch between in the AWS console UI.
| sneak wrote:
| Ungoogled Chromium doesn't serve ads or bundle spyware on by
| default. Firefox does.
|
| Someone should make an automated Unmozilla'd Firefox that rips
| out all phone-home and advertising. I'd run that.
| dijit wrote:
| Like IceWeasel? https://github.com/adonais/iceweasel
| novaRom wrote:
| 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.
| Humphrey wrote:
| 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
| kitsunesoba wrote:
| 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.
| bjeanes wrote:
| 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.
| plonk wrote:
| Was Edge based on Trident? I thought they re-wrote an
| engine from scratch.
| kitsunesoba wrote:
| Edge technically used EdgeHTML, but EdgeHTML was a fork
| of Trident.
|
| https://en.wikipedia.org/wiki/EdgeHTML
| cobalt wrote:
| old edge was trident (which came from IE) new edge is
| based on chromium
| jaxrtech wrote:
| 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...
| themagician wrote:
| You can use more than one browser. I use three.
|
| 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.
| maximmillian wrote:
| What do you use for adblocking on safari macOS?
| bombcar wrote:
| I use Adguard for Safari, seems to work.
| zerop wrote:
| I have been using FF on MacOS. Will checkout this. I moved from
| Chrome and finding this good so far. I face two issues though:
|
| 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.
| clairity wrote:
| 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.
| nrclark wrote:
| 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.
| dewey wrote:
| Would something like this work for you? That's what I'm using
| to switch between proxies but I'm unsure how your VPN setup
| is done.
|
| https://addons.mozilla.org/en-US/firefox/addon/switchyomega/
| Melatonic wrote:
| Can you just have two Firefox users and dedicate one to work
| and personal?
|
| You could also manually specify a DNS provider like
| Cloudflare or NextDNS on the personal user for DoH / DoT
| salmo wrote:
| I do that, but have a "location" for home and work. I flip
| them when I get on/off my company network (VPN or on-prem).
|
| 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?
| hugocbp wrote:
| 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.
| platelminto wrote:
| Thought this was because of Mullvad! I also have this issue
| on FF with Linux Mint.
| zmk5 wrote:
| Mozilla VPN is a skin of Mullvad VPN I believe
| magicalhippo wrote:
| 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.
|
| [1]: https://learn.microsoft.com/en-
| us/windows/win32/sync/critica...
| mnurzia wrote:
| Musl libc also does this for threads, spinning 100 times by
| default before switching to a heavier system wait (see line
| 71): https://git.musl-
| libc.org/cgit/musl/tree/src/thread/pthread_...
| moralestapia wrote:
| nine_k wrote:
| 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.)
| robert_foss wrote:
| Have a look at 'about:performance' to diagnose your CPU usage
| issue.
| solarkraft wrote:
| > 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.
| thecosmicfrog wrote:
| 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?
| lxe wrote:
| 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.
| Vinnl wrote:
| 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.
|
| https://news.ycombinator.com/item?id=33156379
|
| > Here are instructions of using the profiler with just a few
| clicks: https://profiler.firefox.com/
|
| https://news.ycombinator.com/item?id=33156317
| lxe wrote:
| 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.
| lapcat wrote:
| Note that Firefox is distributed outside the Mac App Store,
| otherwise the use of private functions would be disallowed by
| Apple.
| blinkingled wrote:
| I am sure Apple's own Mac App Store apps are free to use those
| though right?
| MBCook wrote:
| Apple, of course, is free to do whatever they want.
| wongarsu wrote:
| A fair and efficient market /s
| poisonarena wrote:
| this is an example of a reddit comment on hacker news,
| there are many more every day
| halikular wrote:
| 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.
| Teckla wrote:
| I have to disagree with you here. Sideloading is either
| "too hard" or "too scary" for many users.
| halikular wrote:
| It's standard practice when installing things on macos.
| Although it's typically signed .dmg's
| sneak wrote:
| 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.
| lapcat wrote:
| > 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.app
| le.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.
| MiddleEndian wrote:
| 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.
| Melatonic wrote:
| F-Droid though is awesome!
|
| 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)
| saagarjha wrote:
| 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.
| ec109685 wrote:
| It's a private flag. Doubtful Apple's review process would be
| able to catch that.
| shadowfacts wrote:
| The flag itself no, but trying to link in
| os_unfair_lock_lock_with_options could be caught.
| why_only_15 wrote:
| 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.
| steve_john wrote:
| mgkimsal wrote:
| > 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.
| sniglom wrote:
| 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.
| dan-robertson wrote:
| 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.
| saagarjha wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-10 23:00 UTC)