> any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?

"Sandboxing every thread" isn't exactly what Chrome does. Chrome provides a separate process for each browser tab. That, of course, requires more memory (since processes cannot directly share memory).

Firefox, on the other hand, uses a single process for the rendering for all tabs, but this process is separate from the main Firefox process. This means that the browser UI is still responsive even if one of the tabs is not responsive.

Of course, actual profiling may yield different results due to other factors that also affect memory usage, but ceteris paribus, using only two processes for n tabs should consume less memory than using n processes for n tabs.

This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.

I'd love to see a 'task manager' that can show CPU usage as well as memory use by individual tabs, because occasionally I see CPU use spike (noticed by laptop fans spinning up) and am reduced to closing random tabs in the hope it'll get better.

> This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.

My experience matches yours.

I think chimeracoder means that's the way Firefox works if e10s is enabled, which wouldn't be true for you unless you've explicitly done so. (I haven't enabled it either)

> any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?

Chrome does process-per-tab more or less. Current plans for e10s are to start with just 1 content process and see how that can be increased later.

So basically e10s does not suffer per-process-overhead as chrome does. For now.

Actually, Chrome does process-per-domain. Almost always several tabs of the same domain will share a process. You can check this by killing one process and seeing lots of tabs go away.

No. We currently mostly do process-per-tab, but it gets complicated depending on how exactly a given window/tab was opened and certain resource heuristics. We're moving to process-per-origin[1], largely for the security improvement. But, that's been a huge, multi-year engineering effort that's only now approaching fruition.

[1] https://www.chromium.org/developers/design-documents/site-is...

I see.

So the reason more than one tab will crash when killing a process is that all those processes were sharing a resource of some sort?

Maybe the trick isn't to do process-per-tab or 1 content process and 1 UI process but to instead do some kind of "intelligent" number of content processes based on CPU and tab count? Like if you had 50 tabs on a quad core processor you could have 1 UI process and say five content processes?

Or another idea, have some kind of upper limit of memory a tab can use before it gets its own process.

That's likely what'll happen eventually. But we're starting with 1 content process because even that is a huge change and is going to cause disruption and will take a while to iron out the wrinkles.