[HN Gopher] Improving Firefox Responsiveness on macOS
___________________________________________________________________
Improving Firefox Responsiveness on macOS
Author : Amorymeltzer
Score : 743 points
Date : 2022-10-10 15:19 UTC (1 days 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.
| dividedbyzero wrote:
| 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.
| 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.
| jupp0r wrote:
| 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).
| gsvelto wrote:
| 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/
| saagarjha wrote:
| Amusingly macOS also has this as SPI, it's used for the
| Objective-C runtime.
| saagarjha wrote:
| You are correct, but there are still places where
| synchronization is necessary.
| 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.
| olliej wrote:
| 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.
| saagarjha wrote:
| Yes but also do note that WebKit is probably among the most
| NIH codebase on the platform.
| olliej wrote:
| 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.
| ben-schaaf wrote:
| Blink uses os_unfair_lock on macOS: https://source.chromi
| um.org/chromium/chromium/src/+/main:bas.... As does
| WebKit: https://github.com/WebKit/WebKit/blob/4c09a48ea41
| 8ff15f65d6c....
| olliej wrote:
| 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.
| saagarjha wrote:
| I fully agree but also want to emphasize that the people
| who work on this at WebKit also enjoy making their own
| stuff.
| saagarjha wrote:
| 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.
| lapcat wrote:
| > 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.
| ccakes wrote:
| Counter argument - https://www.reddit.com/r/swift/ has
| posts within the last few hours.
|
| Granted Swift is technically a cross platform language
| but it feels safe to assume that the vast majority of
| users are developing for macOS and iOS.
| lapcat wrote:
| > 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.
| girvo wrote:
| The vast, _vast_ majority of the posts on there are for
| iOS development. macOS barely gets mentioned.
| olliej wrote:
| 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/
| gsvelto wrote:
| You're confusing general purpose locks with special-purpose
| ones used in the memory allocator. Firefox has its own GP
| locks, you can find them here: https://searchfox.org/mozilla-
| central/search?q=&path=xpcom%2...*
|
| However those are not suitable for use in the memory
| allocator, and neither are WebKit's. WebKit uses
| os_unfair_lock within its memory allocator:
|
| https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de995.
| ..
|
| And so does Chromium:
|
| https://source.chromium.org/chromium/chromium/src/+/main:bas.
| ..
| olliej wrote:
| 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.
|
| os_unfair_lock are a documented part of the OS API: https:/
| /developer.apple.com/documentation/os/1646466-os_unfa...
| Vinnl wrote:
| Just a note thay you're replying to the author, so I'm
| sure they know what it's talking about :)
| saagarjha wrote:
| I get the impression the author was a little hesitant to do
| any spinning in userspace.
| ben-schaaf wrote:
| > 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.
| 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.
| gotenyama wrote:
| Lack of the ability to create app specific window or menu-less
| tab is a huge negative for me right now.
| soheil wrote:
| 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.
| 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 :)
| nick_ wrote:
| Until they match Safari's scrolling responsiveness, it's second-
| rate. No browser I know of achieves the same incredible
| responsiveness of Safari.
| 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
| yinyang_in wrote:
| Using Vivaldi for few weeks now. Seems snappier and have nested
| tab and tab groups natively.
| yoasif_ wrote:
| You may like paxmod: https://github.com/numirias/paxmod or
| TabMixPlus: https://github.com/onemen/TabMixPlus
| 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.
| sexy_seedbox wrote:
| > _multiline tabs_
|
| Curious why you'd want this?
| 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
| ghostpepper wrote:
| 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.
| 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.
| BeeOnRope wrote:
| 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.
| 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).
| soheil wrote:
| 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.
| 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.
| yoasif_ wrote:
| It has been "owned up" to:
| https://github.com/Pocket/extension-save-to-
| pocket/issues/75...
| gnicholas wrote:
| 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.
| 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, ...
| s_ting765 wrote:
| 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.
| 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.
| joeldo wrote:
| That makes sense, thanks.
| bumblebritches5 wrote:
| _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.
| _ph_ wrote:
| No, where would I do that? And of course I can offer litte
| more than the description I gave here.
| viraptor wrote:
| https://bugzilla.mozilla.org/
|
| 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.
| _ph_ wrote:
| I think I went there once and got lost :p I filed a bug
| report, lets see whether anything comes out of that.
| viraptor wrote:
| Thank you :)
| 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.
| aembleton wrote:
| uMatrix can't do cosmetic filtering.
| 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:
| nayeemcodes wrote:
| Manifest V3 is coming!
| 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
| soheil wrote:
| Except that if they don't realize FF is using it and decide to
| drop it completely in their next update. That'd be a fun day
| for FF users.
| 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. ;-)
| jeevestizzobs wrote:
| 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. Then they will use the example to tout
| the App Store.
|
| Especially if you're an org with the pedigree of Mozilla.
| carbonatedmilk wrote:
| 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
| girvo wrote:
| Interesting. It seems like WebKit + Firefox/Chrome WebExtension
| support? So, Safari but with way better extensions?
| 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.
| soheil wrote:
| 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.
| soheil wrote:
| Interesting that Apple doesn't recommend using the technique the
| author describes but instead offers a worse option than the
| deprecated choice.
| 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.
| cbsmith wrote:
| Ahah! We were both looking in the wrong place, as we both
| only found the declarations, not the definition. With
| your pointer, I was able to find it though:
| https://github.com/apple-oss-
| distributions/libplatform/blob/...
|
| 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.
| 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.
| phendrenad2 wrote:
| 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.
| 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.
| nottorp wrote:
| > clone webkit, done by apple
|
| I'm gonna do a Stallman and post a reminder that webkit is
| an evolution of KDE's khtml. Not completely "done by apple"
| or even started by them.
| LtWorf wrote:
| Oh I know. And it's only free software now because it was
| LGPL licensed to begin with.
|
| Otherwise they would have closed it.
| 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.
| gotenyama wrote:
| I'm genuinely curious, have you looked into the lack of good
| sandboxing with Firefox browsers (https://madaidans-
| insecurities.github.io/firefox-chromium.ht...) ?
| barbariangrunge wrote:
| How is firefoxes battery life vs safari in a MacBook?
| hashin wrote:
| 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?
| dcow wrote:
| Edge _is_ Chrome.
| 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.
| wintermutestwin wrote:
| 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).
| stevenhubertron wrote:
| Or Vivaldi natively.
| CRConrad wrote:
| IMO Firefox's open tabs menu is a pretty good stand-in for
| vertical tabs.
| gnicholas wrote:
| Brave is adding vertical tabs. It's currently available via
| flag on Nightly and Dev. Hope they add nested tabs also!
| wintermutestwin wrote:
| 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.
| 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!
| spartanatreyu wrote:
| Just to add to this, even before the upcoming Manifest V3
| switchover, Firefox's uBlock Origin implementation is
| already better than Chrome's.
| 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.
| cassianoleal wrote:
| Why would you need NoScript if you're already using uBO?
| Melatonic wrote:
| Security mainly - a site I do not trust
| 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.
| nicoburns wrote:
| IMO Firefox with a few extensions is much better than brave
| for the first.
| 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).
| vladvasiliu wrote:
| 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.
| 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
| lawgimenez wrote:
| 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.
| KptMarchewa wrote:
| On iOS it's the same engine safari uses.
| kibwen wrote:
| 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.
| BeefWellington wrote:
| 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.
| kibwen wrote:
| Ah, I'm aware of the feature in the devtools, but I
| thought this feature was designed to capture the
| performance of the browser UI itself.
| depr wrote:
| That also exists, see https://profiler.firefox.com
|
| I am sure Mozilla would appreciate a bug filed in
| Bugzilla if you can.
| sfink wrote:
| 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.)
| 3836293648 wrote:
| No, I've heard of people using it for years. They
| probably just moved it to make it more visible
| 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.
| nicoburns wrote:
| 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.
| kennydude wrote:
| 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,
| hamandcheese wrote:
| > so sometimes when they open a template they end up having a
| couple hundred of these editors hidden behind drag and drop
| enabled accordions.
|
| What if you only loaded/initialized the editors when they
| became visible?
| laundermaf wrote:
| > just write my own WYSIWYG editor
|
| 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.
| girvo wrote:
| https://ckeditor.com/blog/ContentEditable-The-Good-the-
| Bad-a...
|
| Or
|
| https://medium.engineering/why-contenteditable-is-
| terrible-1...
|
| Are two that I remember reading... nearly 10 years ago,
| holy hell can someone please make time slow down? Which
| discuss the common API pitfalls with `contenteditable` --
| though I've no idea how painful it is in 2022. Could be a
| lot better now?
| laundermaf wrote:
| Ah yes the second one is exactly it.
|
| > 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.
| [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/
| faebi wrote:
| 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.
| 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.
| soheil wrote:
| There are also a lot of Chrome extensions that do the same: h
| ttps://chrome.google.com/webstore/detail/multilogin/ijfggli..
| .
|
| 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.
| toyg wrote:
| 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.
| sfink wrote:
| 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.
| soheil wrote:
| 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.
| toyg wrote:
| 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.
| bumblebritches5 wrote:
| a254613e wrote:
| I gave it a go:
|
| * 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.
| 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
| josephb wrote:
| I use https://librewolf.net/ which I think might be close to
| what you are looking for?
| 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.
| hvis wrote:
| To quote the article: 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.
| saagarjha wrote:
| This conclusion does not have sufficient supporting
| evidence in the blog post.
| jabedude wrote:
| 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
| azinman2 wrote:
| Memory allocation is one of many differences between the
| browsers.
| jhatax wrote:
| Or implement their own locks and support structures to eke
| out performance [1]. Hat tip to @pizlonator.
|
| 1. https://webkit.org/blog/6161/locking-in-webkit/
| 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
| ipaddr wrote:
| Sounds like a problem with the os. Ever consider switching?
| orhmeh09 wrote:
| Is there an OS and hardware combination you suggest for
| 18 hours of Firefox, TypeScript, and Docker?
| kuschku wrote:
| Linux, ThinkPad T470 with the big 95Wh battery.
|
| Bonus: Charging your mobile phone takes less percents off
| your battery life than with a macbook.
| maccam94 wrote:
| 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.
| pxc wrote:
| 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.)
| sscarduzio wrote:
| Having the same issue, patiently waiting for Asahi Linux
| to deliver.
| girvo wrote:
| 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.
| 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.
| dblohm7 wrote:
| 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.
| 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...
| ho_schi wrote:
| * 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.
|
| And? Maybe there is a new engine on the block:
|
| https://github.com/SerenityOS/ladybird
|
| PS: I think the Epiphany guys doing a nice job but need
| more developers. The upcoming release will support Web-
| Extensions.
| thrusong wrote:
| I use teams.microsoft.com in Firefox all work week
| without issue.
| KptMarchewa wrote:
| 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.
| dmitriid wrote:
| Chrome (Blink) and WebKit are two different engines.
|
| It's Chrome dominating, Webkit a somewhat distant second
| [1], and Firefox a third, quickly disappearing into
| oblivion [2].
|
| [1] There's a huge number of weird versions of WebKit
| running on TVs and such.
|
| [2] It's barely around 200M users, but it's bleeding
| users slowly and surely
| https://data.firefox.com/dashboard/user-activity and
| https://news.itsfoss.com/firefox-decline/
| 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?
| themagician wrote:
| Adblock Plus, Firefox Focus, Hush, Ghostery and
| Malwarebytes on iOS.
|
| Adblock Plus, Ghostery, and Hush on macOS.
| raydev wrote:
| Do any of these block YouTube ads?
| interpol_p wrote:
| 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.
|
| [1] https://andadinosaur.com/launch-vinegar
| dmix wrote:
| > 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.
| themagician wrote:
| YouTube Premium for life. Haven't seen an ad on YouTube
| since 2015. Not going back now.
| bombcar wrote:
| I use Adguard for Safari, seems to work.
| raydev wrote:
| Doesn't Adguard require running a separate app?
| bombcar wrote:
| It may, I can't remember. It's managed through Safari for
| me.
| jandorn wrote:
| There is AdGuard Safari extension and AdGuard app.
| girvo wrote:
| I use 1Blocker on both macOS and iOS
| nicoburns wrote:
| 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.
| soheil wrote:
| Certainly YouTube isn't snappier than in Chrome at all. Most
| other sites feel the same or faster, however.
| azinman2 wrote:
| 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.
| 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
| soheil wrote:
| In what cases did you notice key type response being slower
| than Chrome? I feel like you have to have pretty incredible
| spidey senses to detect that.
| 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.
| williamscales wrote:
| I thought browsers on Mac were just skins over Safari? Does this
| mean I can run real Firefox on my iPad at last?
| plantain wrote:
| MacOS, not iPadOS.
| lelandfe wrote:
| Browsers on iOS are, not macOS.
|
| No, iPad is not affected.
| 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.
| gotenyama wrote:
| This is greatly related to the lack of per-tab sandboxing in
| Firefox (https://madaidans-insecurities.github.io/firefox-
| chromium.ht...) it's not only a security issue but a
| performance issue as well.
| 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.
| Vinnl wrote:
| Ah, that's a bummer indeed! Possibly devs can help you get
| more useful data if you report the bug first?
| 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)
| stu2b50 wrote:
| 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.
| nickm12 wrote:
| 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).
| lapcat wrote:
| Mac App Store has a ton of scams.
| https://mjtsai.com/blog/2022/04/15/mac-app-store-
| ransomware/ https://mjtsai.com/blog/2022/08/10/the-top-pdf-
| reader-in-the...
|
| iOS App Store too. They're not safe. Apple isn't going to
| steal your credit card, but they'll happily charge your
| credit card for these scams.
| stu2b50 wrote:
| And that's fine. It's a heuristic. A coarse filter. But a
| filter none-the-less.
| tpush wrote:
| These scam apps are literally #1 in the App Store. The
| filter ist practically useless, if not outright harmful
| in this case.
| Barrin92 wrote:
| 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.
| 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.
| soheil wrote:
| 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.
| 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.
| soheil wrote:
| By probably monitoring CPU cache hit rates would be one way.
| dan-robertson wrote:
| Is there even a way to access cache hit rates on MacOS?
| soheil wrote:
| You can probably infer them by measuring computation time.
| enragedcacti wrote:
| > 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.
|
| https://jemalloc.net/jemalloc.3.html (see "Implementation
| Notes")
| 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.
| olliej wrote:
| Firefox could of course just do what webkit does, and implement
| the spin lock themselves:
|
| https://github.com/WebKit/WebKit/blob/ae32cf14a9c1570e6ea8d2...
___________________________________________________________________
(page generated 2022-10-11 23:02 UTC)