What will Basilisk's parralel-processing be like. Will it have comparable gains to electrolysis?

[avada]

Hi!

So it's explicitly stated that "Does not use Electrolysis (e10s, multi-process browsing)". But Moonchild made some vague remarks about "parallelizing libraries at a lower level" or "making things multi-threaded and multi-core/parallel at the lower level".

So I wonder how that works, could it perform as well (as much as gains go) as e10s multi-processing can.
For example: could tabs load/function independently without interference from each other and use different CPU cores?

[adisib]

use different CPU cores?

Open up a page in Pale Moon while having task manager showing per core usage. You will see that Pale Moon uses multiple cores without using electrolysis.

The difference that you can notice that comes from using multiple processes like electrolysis is that if a crash occurs, that crash can possibly only result in a single tab being closed, rather than the whole browser. At the same time, using a multiple process approach like electrolysis will make the code base much more complicated which will probably mean you crash more often than without electrolysis.

[avada]

use different CPU cores?

Open up a page in Pale Moon while having task manager showing per core usage. You will see that Pale Moon uses multiple cores without using electrolysis.

The difference that you can notice that comes from using multiple processes like electrolysis is that if a crash occurs, that crash can possibly only result in a single tab being closed, rather than the whole browser. At the same time, using a multiple process approach like electrolysis will make the code base much more complicated which will probably mean you crash more often than without electrolysis.

I see. So isn't it possible for only the tab to crash?

[adesh]

Electrolysis is not "one process per tab" model, Chrome/Chromium is the only browser to do that. Mozilla's project just uses different processes for differenet tasks - one process to manage the browser UI (UI process) and one or more content processes to manage the web content in tabs. This means that, in cases of several open tabs, a content process may manage content of more than one tabs, and hence, crashing of a content process may take multiple tabs down with it.

Also, note that it does not result in improved real performance (throughput), but rather a perceived performance gain where browser seems to be more responsive (because UI drawing is done independently from tab content). One benefit of this is that a CPU intensive webpage will not stop browser from accepting user commands and freezing the browser.

You can change the number of content process through about:config hackery, but current consensus seems to be that anything above 8 will negate the performance gains.

Multitaksing and parallel processing are different from Mozilla's Electrolysis.

[Moonchild]

current consensus seems to be that anything above 8 will negate the performance gains.

I think the problem is that people also seem to be confused about performance gain here. Because of the way e10s works, and because it must talk to and transfer (regularly huge amounts of) data to the main (UI) process for every action performed, every element cached and every other operation that can't be done in a restricted content process, there is no direct performance gain, and in fact the overhead for each process and the system overhead for passing data back and forth between processes can't be ignored either; this overhead will also increase with each additional content process used and is a pure performance sink. Inter-process communication has a cost that is often conveniently ignored by proponents of e10s.
As stated it is only user perception that benefits here; but user perception won't benefit if the browser overall becomes less responsive or loads your system more for its internal communication, even if the UI remains more responsive. If you click a button and it responds with visual feedback that you clicked it, but there's a delay before the actual action associated with the button is performed, is that a gain? I think not.

In fact, my own practical experiences (from using Firefox and Nightly) are that there is a noticeable performance loss when e10s is enabled, with clear delays for every action performed.

[avada]

Electrolysis is not "one process per tab" model, Chrome/Chromium is the only browser to do that. Mozilla's project just uses different processes for differenet tasks - one process to manage the browser UI (UI process) and one or more content processes to manage the web content in tabs. This means that, in cases of several open tabs, a content process may manage content of more than one tabs, and hence, crashing of a content process may take multiple tabs down with it.

Well, I increased dom.ipc.processCount to a large value so most times the tabs indeed have separate content processes.
Also it's not true anymore. They even increased the number of processes by default to four.

Also, note that it does not result in improved real performance (throughput), but rather a perceived performance gain where browser seems to be more responsive (because UI drawing is done independently from tab content). One benefit of this is that a CPU intensive webpage will not stop browser from accepting user commands and freezing the browser.

This isn't true either because of the above. Particularly with the increased content process count that I have for years.

You can change the number of content process through about:config hackery, but current consensus seems to be that anything above 8 will negate the performance gains.

As long as you have enough RAM it doesn't, in my experience. When the swapfile gets used extensively it starts to suck.

Multitaksing and parallel processing are different from Mozilla's Electrolysis.

I know, otherwise I wouldn't have submitted this topic. But for starters, I don't know whether it's possible achieve such degree of separation as with different processes.

[hujan86]

In fact, my own practical experiences (from using Firefox and Nightly) are that there is a noticeable performance loss when e10s is enabled, with clear delays for every action performed.

To think some people kept bitching about how "obsolete" Pale Moon is just because there's no Electrolysis support.

[avada]

Hmmm.

It seems like electrolysis options are present and functioning in basilisk. I had force enabled in the profile I tested. About:support shows it's enabled and I see multiple content processes appearing.

[Moonchild]

Of course if you want to tinker with it you can force-enable it in basilisk (for now). Running it like that is completely unsupported though.
It's no different than other code that is still available in the platform; doesn't mean that it's wise or smart to use it
As a platform, other applications may want to use multi-process as well; I'd like to think broader than just Basilisk for UXP.

[MoonExplorer]

I'm sorry, but you are wrong. It doesn't all come down just to perception improvements. Try loading multiple tabs simultaneously with 4 content processes (thus utilizing all cores) and you'll see a 3-3.5x speed gain.
There are also situations where you have one or many tabs opened (e.g. youtube) that load CPU too much for other tabs to work smoothly as they should, let alone the browser interface (I understood you completely discard interface responsiveness as an improvement). In Firefox and Chromium that's not an issue, because that heavy tab can do whatever it wants, it won't affect performance of most of the other tabs .
As for your performance loss using Nightly (btw what Nightly versions were that?), I think it can be attributed to using of the so-called shimmed addons that don't support e10s.
Tbh I don't understand why one has to be in denial about all this...

[Moonchild]

So, because I don't agree with the marketing speak conveniently ignoring all the drawbacks, I'm in denial, now?

Locking this thread.