effects of e10s in single process mode

[joe04]

This is a tangent off of Moonchild's recent post "Multi-process, or: the drawbacks nobody ever talks about".

I respect the arguments he makes on their technical merits, but I'm wondering about the actual state of the Pale Moon and UXP codebases. Given that Mozilla has made a ton of changes over the course of several years to implement e10s, to what extent has that introduced inefficiencies when always running in non-e10s mode?

(This is an academic curiosity on my part. I'm not requesting any changes; the current v27.6.2 functions quite well for my particular workflow and customizations.)

Here's a specific example:
Back in January I posted a review of the earliest Unstable builds, which would soon become the 27.1 release. For me, this was the big jump from v26.5 to v27, which meant going from (in somewhat oversimplified terms) Firefox 24 ESR to 38 ESR under-the-hood capabilities.
One particular change I observed was color toggling (using a forerunner of my Dark Toggle extension) occasionally having a bit of visual lag that I hadn't seen in prior versions. Moonchild then explained: You have to understand that on-the-fly style and metrics changes have been made mostly asynchronous. What you see isn't "jank" as such, since it's not that the main thread is so busy it can't process anything else, but rather the opposite: a noticeable delay of the main loop needing more runs to process asynchronously-dispatched restyling. "a waiting for b waiting for c waiting for d to be done"

This is interesting because it implies that e10s-style asynchronicity is written into the code such that even in single-process mode its control flow still has to use it.

[New Tobin Paradigm]

Pale Moon's application code has barely any e10s functionality and we have even removed some.. The Platform as of Tycho and especially Moebius (UXP) has it in there but it has never been complete and is unstable as hell.

As for what impacts does it have on non-e10s mode? Well besides making the code that IS e10s aware more complicated it also has to do a check every time to SEE if it is supposed to use an e10s codepath or not.

Once we get UXP stabilized to a point that can be considered Pale Moon ready (which is the quality level most of you expect) we can start to unravel the tangled mess of e10s and obliterate it from our codebase once and for all.. But this will be a time permitting on-going operation. So even if you use Basilisk and turn e10s on know that it will degrade over time and will become busted as we work through removing it.

UXP can only be used reliable in a non-e10s mode. No one will be supporting the e10s mess and it will become quite busted as we start to sort through and cull the e10s disaster.

[joe04]

Thanks for the helpful response. Good to know you have a nuke in the arsenal for e10s