Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multi-process Firefox brings 400-700% improvement in responsiveness

techcrunch.com

Post reply on HN
Print view View original

41–50 of 346 posts

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#41

Post by gsnedders »

theandrewbailey wrote: post #36
TheCoreh wrote: post #11

Earlier quoted context omitted.

As with most native A/B tests, the binary probably ships with code for both functionalities. When the browser launches for the first time they generate a random number, and if it's below a certain threshold you get variant A, above you get variant B. The information gets persisted on disk so it remains unchanged across sessions.

It seems that there is some communication back to Mozilla, since they claim that they can increase or decrease the number of users in each group over a week; that seems unlikely to come in the form of a new binary.

Non-stable channels get frequent builds, so it's not implausible it's a new binary.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#42

Post by dogma1138 »

formula1 wrote: post #37
schoen wrote: post #28

Earlier quoted context omitted.

Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?

One thing that firefox does well is suspend pages you are not using and likely saving the state of the appllication to the disk. Another thing can be for when multiple pages use the same or similar javascript/css/external respurce files, they only need to be loaded once into memory. Another thing canbe that certain javascript globals would only be loaded when the getter asks for them. Something like AudioContext and…

If that's that case I much rather my browser eat up more RAM than needlessly write to my SSD.

A lot of the improvement in the reliability of consumer grade SSDs is due to OS improvements in how they manage their write operations to the hard drive. Windows is considerably more conservative in how it uses it's page file and what does it write off to the SSD, linux has also made a lot of improvements in how it uses the swap partition if it uses it at all, other things like having to be able to suspend the PC in "hibernation" mode without actually having to write a "hibernation" file to disk by keeping the CPU at pretty much an off state but refreshing the ram also saves a lot of day to day write operations especially on mobile devices.

So overall I highly doubt that Firefox went with the suspend to disk route, because if it did it would be a pretty big step backwards.

Also as power conservation goes writing to SSD/HDD is more expensive than writing to RAM and keeping it refreshed, so using the SSD as a storage device instead of the RAM can also have negative effects on the battery life of mobile devices.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#43

Post by the8472 »

schoen wrote: post #28
rsp1984 wrote: post #19

“We can learn from the competition,” said Dotzler. “The way they implemented multi-process is RAM-intensive, it can get out of hand. We are learning from them and building an architecture that doesn’t eat all your RAM.” That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff…

Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?

a) your security should not rely on process isolation. the javascript engine etc. should be secure in the first place. if you can break out of the JS sandbox you can already attack addon scripts (think password managers)

b) hosting some tabs in the same, sandboxed process is still stronger than hosting all of them in the parent process.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#44

Post by creshal »

0xfeba wrote: post #32
schoen wrote: post #28

Earlier quoted context omitted.

Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?

Duplicated memory and just overhead from running separate processes (Chrome), as opposed to shared memory and less overhead from a single process (IE? Old FF). As for security, no, unless there's some unknown vulnerability now (or that they create), that will be ported over and somehow more effective between (potential) processes. So, I doubt it.

Chrome uses separate processes for sandboxing purposes, not just for the fun of it. So yes, protecting against "some unknown vulnerability" is the entire point behind it.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#45

Post by rl3 »

This will probably have significant implications for web worker behavior.

If memory serves, workers are unable to directly communicate with each other in Firefox when the UI thread is blocked, because message handling runs on the same process as the UI thread. Chrome doesn't have that limitation since it's already a multi-process architecture.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#46

Post by [deleted] »

rsp1984 wrote: post #19

“We can learn from the competition,” said Dotzler. “The way they implemented multi-process is RAM-intensive, it can get out of hand. We are learning from them and building an architecture that doesn’t eat all your RAM.” That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff…

[deleted]

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#47

Post by nfriedly »

nl wrote: post #7

I switched to Firefox from Chrome about 12 months ago. It isn't as good as Chrome, but I was trying to reduce my Google dependencies. It has been mostly fine (except for an annoying OS-X multi-screen bug where it screws up the sizing). I was really looking forward to this feature to help close the gap on Chrome performance. Until August (I think Firefox 48.x), when it became unusable on any site with... something. I'…

> No add-ins (except for Firebug).

You might want to try Firefox's built-in Web Console. I switched a year or two ago when it was less powerful than Firebug, but notably more stable, and I haven't gone back since.

> except for an annoying OS-X multi-screen bug where it screws up the sizing

Can't argue with you there. At last exiting full-screen video no longer takes the entire browser out of full-screen.

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#48

Post by creshal »

addicted wrote: post #33
uuoc wrote: post #14

This should come as no surprise. It has always been an epic architectural mistake to use the same single non-reentrant Javascript engine to both render the UI and run JS for webpages in Firefox. This change will finally undo that huge mistake made so very long ago.

JavaScript was little more than a toy scripting language used to animate stuff and change layouts when html/Css wouldn't fit for the greatest part of firefox's early existence. At the time it was probably the appropriate decision. Now, it's a huge burden on Firefox and it's good to finally see progress on this front.

> JavaScript was little more than a toy scripting language

No, back then Mozilla was trying to do the entire UI logic in JS. That was the whole point behind reusing the same JS engine for both: https://en.wikipedia.org/wiki/XUL

Re: Multi-process Firefox brings 400-700% improvement in responsiveness

#50

Post by scott_s »

faragon wrote: post #12

Why? Except because of memory allocation serialization impact, there is no reason for a multithreaded process being slower than multiprocess. And if that's the cause, it could be solved using multiple heaps.

My guess is that the multithreaded-only design wasn't as good at exploiting the inherent per-tab parallelism. The original architecture probably had some synchronization points (perhaps related to the common GUI code) that did not allow processing each tab truly independently. Regarding memory allocation, yes, in theory one should be able to try to avoid sharing data across threads, which should eliminate serialization on memory allocation and deallocation. But I can easily imagine that in practice, in a codebase that was not explicitly designed to process each tab in parallel, you'll still end up sometimes sharing data across threads.

I imagine they could have instead changed the architecture to be multithreaded in such a way to avoid my imagined sequential bottlenecks, but performance is not the only goal in a multprocess architecture. Sandboxing is another design goal, and that cannot be fully achieved with a multithreaded design.

This is all speculation on my part, so if anyone who actually works on the Firefox codebase could correct me, that would be very welcomed.

Post reply on HN