nadark wrote:Wasn't there some talk about making a seperate process that would only have elevated privilages and handle I/O?
e10s? That was the goal 4 - 5 years ago, it has since then stopped and Mozilla are now working on threads instead of process. Which in terms of memory usage is a definitely good thing.
nadark wrote:Wasn't there some talk about making a seperate process that would only have elevated privilages and handle I/O?
e10s? That was the goal 4 - 5 years ago, it has since then stopped and Mozilla are now working on threads instead of process. Which in terms of memory usage is a definitely good thing.
So even though they are just doing separate threads for the UI instead of a separate process like Chrome, is the end result still going to be that Firefox becomes as fluid and responsive as Chrome? Or will it just be somewhat of an improvement compared to what we have now? I'm talking in real world usage, not benchmarks or anything. So many times when I switch or open new tabs, navigate the menus ect there is a distinct lag with Firefox that I don't get on Chrome. That's what I'm talking about when I mean fluid.
The responsiveness of the browser's interface should be just as responsive at all times, regardless of what's happening in tabs (assuming they don't use all CPU power).
nadark wrote:Wasn't there some talk about making a seperate process that would only have elevated privilages and handle I/O?
e10s? That was the goal 4 - 5 years ago, it has since then stopped and Mozilla are now working on threads instead of process. Which in terms of memory usage is a definitely good thing.
So even though they are just doing separate threads for the UI instead of a separate process like Chrome, is the end result still going to be that Firefox becomes as fluid and responsive as Chrome? Or will it just be somewhat of an improvement compared to what we have now? I'm talking in real world usage, not benchmarks or anything. So many times when I switch or open new tabs, navigate the menus ect there is a distinct lag with Firefox that I don't get on Chrome. That's what I'm talking about when I mean fluid.
I think after all these years and discussions. The truth is no body knows; Even the Devs. Theoretically it should be.
Multi-process buys you some protection against crashes, but communication between processes is usually slower than communication between threads (though I'm sure they've developed lots of clever ways to make it as fast as possible).
Good point, I forgot about that. Still, that means we'll have an extra process like plugin-container.exe to handle IO, it doesn't mean the main process will be split between tabs.
nadark wrote:No, twas not e10s, it was something more recent. After a bit of scavanging around bugzilla. Here, https://bugzilla.mozilla.org/show_bug.cgi?id=730956 They mention a shim process that would only handle IO
Wasn't that given up in the end for SuperSnappy? If i record correctly.
I feel the same way about multi-process as I do about 64bit - it doesn't really matter for me as long as Firefox loads pages fast and remains responsive.
And for a single process 32bit application with a ton of addons my god is it fast even on slow PC's. Bring on 2013!
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86 Mobile:Xiaomi Redmi Note 3 Pro
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.
