Hacker News Reader

Comment by djanogo | Hacker News Reader

I was thinking about Firefox development quality while trying to figure out why the f does Firefox CPU usage fluctuate between 1 and 5% with one background tab open and only one plugin installed (containers). The same URL when opened in safari goes to 0.1% or 0.0. I tried to look up dom timeout config settings and tried to set aggressive timeouts, but in the end I gave up.

There must be something fundamentally wrong if apps can't stfu and be at 0% while in background with simplest use case. I am going back to close app's when I am done using it.

View on HN

If you want to find out yourself, I can highly suggest using the Firefox Profiler on https://profiler.firefox.com/ - amazing tool!

Besides the devtools profiler, which may not capture everything there's a whole-application profiler for firefox, that might provide some insight: https://profiler.firefox.com/ But try the devtools one first, it's easier to use.

the f does Firefox ... same URL when opened in safari

It would be interesting to compare the safari budget/manpower. Even given that, I would imagine safari only has to support one-ish OS, and probably has help from the OS group.

The WebKit team is smaller than the corresponding team at Mozilla, even if you look at the subset of of identical roles across both organizations (and e.g. ignore those working on the Firefox network stack).

That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS libraries in a way neither Firefox nor Chrome do.

Safari for Windows is discontinued isn't it?

Yes. But as sibling comments said, iTunes and iCloud both use WebKit.

Who uses WebKit on Windows?

I bet iTunes does for the storefront.

Yeah, also the iCloud client

Microsoft. (Well, I guess it's blink now.)

would there be a corresponding safari team separate from webkit? I wonder if webkit might have (and benefit from) multiple internal "customers".

It's organisationally under the Safari team, as far as I'm aware.

as of the last time i recall the window server had some special treatment for safari to try to optimize various things -- is that true?

I'm unaware of any special treatment (but that doesn't mean there is none!), beyond Apple caring about battery life in general on their OS and I would strongly expect that the browser forms part typical-use testing of the OS and as such influences what parts get targeted for performance work.

Certainly Apple's WebKit port uses Core Animation heavily, which is definitely heavily tied to the compositor in the window server.

Safari definitely uses private APIs (or at least did at one point) to manipulate out-of-process layers more directly than the public CA API lets you do.

Hey, I've been trying to remember something about the way CA and the windowserver interact for a few weeks but I can't find anything about it. I remember somewhere there was a setting for maybe the backing layer of how a window was set up? And there were a few hidden ones? i remember that one of these settings was how minimized windows were implemented because the layer was set up to copy some other layer, and then shrunken, so that way you get minimized windows changing when the window changes for free.

Ah, yeah, it does seem to still do that. For some reason I thought that those APIs had been made public, but alas no.

In my experience (which includes using both Firefox and Chrome on a Linux VDI which is particularly CPU-constrained), I've noticed that Firefox's event loop handling seems pretty poor, and seems to redraw/paint even a blank page (and has a full core of CPU usage for doing nothing), whereas Chrome is fully-idle and has no CPU usage in the same scenario. Minimising Firefox is the only way I've found to stop it updating the VDI's content and using CPU.

Things (on the same constrained resources VDI) get even worse with actual "complicated" content: viewing the same page which contains an animated GIF, Firefox seems to prioritise playing back the content, even at the expense of noticing/obeying user-interface interaction like closing tabs and opening menus: i.e. gifs will keep playing (very slowly), but it won't notice UI clicks on its interface for many seconds seconds.

In the same scenario, Chrome responds to UI events much more quickly (very nearly instantly).

It's possible this is due to hardware acceleration or something, but as both are running in the same VDI that barely seems to have OpenGL 2.0 support (I can't run modern OpenGL apps), that seems unlikely to me...

In addition to what others have suggested you might want to check how many things you have registered under about:serviceworkers (type that in as the URL), there might be something in there running far more than is reasonable.

I’ve gotten in the habit of killing Firefox before going to bed, the processes seem to run away and peg the CPU periodically throughout the night. It seems to be generally Facebook, but other JS heavy sites have similar issues.

Google Calendar has had some serious issues with doi g something weird in the background.

At some point Google search results page also would spinn up one core on my machine one or twice a minute if left unattended but last I saw that was years ago. (FWIW I don't use Google search much these days, so it might slip by without me noticing.)

I don’t understand why tabs are allowed to mindlessly peg CPU, especially after the wave of crypto miners

This is beyond me as well but I chalk it up to our entire field being immature, which means there are endless possibilities and endless chaos.

IMO background activity should need an extra permission similar to notifications and geolocation.

But we need to sort out UX (and start punishing the companies that "misunderstand" GDPR to mean they just need to add another popup) as it is starting to get bad now.

BTW, this needs to be fixed across a number of situations. There's no reason why I would want to allow a build tool to access all my projects just because I want to allow it to access one project. (Github and Azure Devops, I'm looking at you)

Why wouldn't you poweroff/hibernate computer for the night? Isn't that just a waste of electricity?

Depends on how you look at it, I need to keep state of work things (emacs sessions etc). But compared to my fridge or pretty much any industrial country my computers electricity consumption is near negligible.

Fair enough, though I'm fairly sure my computer, even when idle, draws more power than my fridge.

Chrome has the same issue. The thing is, Safari is deeply connected to OS X and its internals to save as much energy as possible. Apple can do this and tie the code to the specific hardware, kernel, and what else matters that Safari runs on as they control everything. Chrome and Firefox cannot.

I would not be surprised if someone tells me that parts of Safari hook into private APIs in the kernel, the graphics driver and the other parts of the graphic and input stack to achieve the (measurable!) performance advantage over other browsers. For me personally, this is uncompetitive behavior that should be punished, but oh well, anti-trust legislation isn't exactly something that got much use over the last decades :(

You think Apple should be punished for creating a vertically integrated stack?

Setting aside private APIs as I have no idea what Safari does or doesn't use (although vast portions of it are open source, enough that you can compile modern versions of WebKit and "upgrade" the ancient WebKit on PowerPC Macs), another browser could be just as closely integrated as Safari. Obviously, the cost/benefit ratio is awful for Mozilla and Google, so they won't, but why should Apple cripple their own software? Safari's development costs, as part of MacOS, are funded by profits from Mac sales. Safari is deeply integrated with MacOS which is in turn deeply integrated with the Mac.

In my opinion the whole point of the Mac is this vertical integration, and the main value-add of Apple's sphere. If you don't value that, there are cheaper options where cheaper and more flexible software is available.

To me, an anti-trust suit would make sense for Safari on iOS, where Apple has locked all competitors out (in practice). Saying Apple should be fined for Safari because it's more integrated and efficient and that's not fair to Chrome and Firefox seems a bit silly, especially given (desktop) Safari's relatively small usage numbers. All IMO of course.

> You think Apple should be punished for creating a vertically integrated stack?

No, only for not giving everyone a fair and equal level of access. I'm not against Apple deeply integrating Safari into the OS, but they should allow competition to enjoy the same level of performance that their own stuff does.

> I would not be surprised if someone tells me that parts of Safari hook into private APIs in the kernel, the graphics driver and the other parts of the graphic and input stack to achieve the (measurable!) performance advantage over other browsers. For me personally, this is uncompetitive behavior that should be punished, but oh well, anti-trust legislation isn't exactly something that got much use over the last decades :(

In the absence of any evidence of this — have you looked at the open source releases? — why is that more plausible than a team employed by a hardware vendor which cares deeply about user experience and battery life prioritizing use of the platform features and talking with other teams at the same company? Part of what makes things like Firefox' compositor work hard is that they support multiple other platforms so the Safari team can easily be ahead without anything underhanded simply by virtue of not needing to support 4 major platforms.

The rendering engine is open source. You’re welcome to audit it here: https://webkit.org/getting-the-code/

Doesn't Safari also lag in implementing new or battery-hungry features? I suspect that could be a big factor too.

Antitrust legislation? For a company that has like a tenth of the market, tops? Be serious.

Reply on news.ycombinator.com