uBlock under e10s slows entire browser when loading pages that make many HTTP requests

[ChimeraCoder]

This may be related to #214, but I think it's slightly different. I've experienced this in several different versions of Firefox that are running with e10s (electrolysis) enabled.

When loading a page that makes many (e.g. 100 or more) HTTP requests on the first load, uBlock slows down the entire browser until that page is done loading, which can easily be 20+ seconds. The rest of the UI is responsive, so I can switch to another tab, but because the rendering process is blocked, those tabs also simply display the infamous "loading wheel" until the other page is done rendering.

I have one website which makes 600 HTTP requests on the first load (all images), and it renders the entire browser unusable for 30 seconds when I load it with uBlock enabled. With uBlock disabled, it loads almost instantaneously.

To note: uBlock isn't the only extension that has this problem. Similar extensions like Ghostery and Noscript also cause the problem as well, and the problem is much worse if more than one of these extensions is installed simultaneously. But since the problem is noticeable even when uBlock is the only extension installed, it seems to merit filing a ticket here. I mention the other extensions only because there is likely significant overlap between users of these extensions, and for them, the issue will be compounded.

[gorhill]

I have one website

URL?

[ChimeraCoder]

@gorhill The best example I have (with the 600+ requests) is a company directory with headshots, which is unfortunately private or I'd include it. Toodledo's logged-in homepage is also an offender, but if you don't already have an account with lots of tasks, that won't be very helpful for testing either.

I tested it out on the NYTimes homepage, and it's it's noticeably slower, but nowhere near as drastic (ie, I can tell the difference there without using profiling tools, but I wouldn't be bothered by it if I weren't consciously looking for it).

I'll try and keep an eye out for sites that exhibit this behavior and don't require a login; I know that this will be tough to test otherwise.

[gorhill]

I tested it out on the NYTimes homepage, and it's it's noticeably slower

Slower than what?

I just tested the front page http://www.nytimes.com/ with and without uBlock default settings (with disable/enable as per #214), e10s, cache disabled, and the difference with uBlock and without uBlock is day and night, i.e. without uBlock the page takes forever to finish fully loading.

[SW1FT]

This looks like it's a problem with your Firefox profile, try making a new one and see if it happens.

[ChimeraCoder]

@gorhill To clarify, I'm not talking about how long the page takes to load. I'm talking about whether or not it prevents usage of other tabs (which have already been loaded) while the tab is loading. This is the e10s 'rendering wheel' that I'm talking about; I know Mozilla has a term for it, but I'm blanking on what it is:

Under e10s, this will be displayed in the center of the tab instead of the content while waiting for the rendering process to respond.

@SW1FT Yes, I'm testing this in a blank profile.

These are the steps I'm taking:

1. Open Firefox with a blank profile (mktemp -d and set --profile to the temporary directory)
2. Disable disk and memory cache in about:config, and enable e10s.
3. Open an Amazon item page (this makes 200+ HTTP requests on the first load for me)
4. Open a Github issue page which has a lot of comments. I happened to use issue 942 on the opal/opal project page. (I'm not linking to it directly so the mention doesn't register there, as it's not actually a related issue).
5. Reload the Amazon page and immediately switch to the Github issue page. (For good measure, switch back and forth several times until the Amazon page is fully loaded).

When I do this without uBlock installed, the Amazon page may take several seconds to load, but it never blocks the rendering process long enough to cause a spinning wheel on the Github page.

If I install uBlock and repeat steps 1-5, the Github page will sometimes display the spinning wheel briefly (less than a second) when I switch to it. For other pages, I sometimes experience this for several seconds or more, which renders all tabs on the browser unusable during this time.

I wouldn't be surprised if the issue had to do with the shims that the SDK uses, which are mentioned in #214, but since the behavior here is different I believe it may be a slightly different issue.

[Mikey1993]

@ChimeraCoder This seems like something that Mozilla can help to figure out. Probabaly FF with uBlock does something that blocks/helps to block the renderer on that tab switch.

e10s are currently under heavy development, so bugs and issue are natural. Better for you to open a new bug at bugzilla (https://bugzilla.mozilla.org/enter_bug.cgi) and link this issue on the bug for reference.

[benyaminl]

E10S isn't stable yet and cause alot of mess, so I think uBlock have nothing to do with it. Btw if you use adblock, it become more worst, your browser lag and stop working.

[ChimeraCoder]

@gorhill For some reason I can't find your last comment from the other day - was it deleted?

In any case I have a strong feeling that sendAsyncMessage would indeed fix this issue, as you said. I wasn't able to compile uBlock with this change locally (I have issues with cfx on this machine), but if someone shares an xpi file I'd be happy to test it and confirm that it fixes the bug.

[gorhill]

was it deleted?

Yes, I decided I would rather try the idea whenever I have time rather than speculate pointlessly about it.

[silverwind]

On Nightly with e10s enabled, I sometimes get a jank warning modal bar about uBlock Origin.

about:performance does show a pretty high CPOW number:

This might not be strictly related to @ChimeraCoder's issue because browsing seems quite smooth for me, it's probably just related to startup (rules loading?).

[gorhill]

@silverwind Did you disable/enable uBlock after launching Nightly? This bug causes a whole lots of CPOW warnings, unless you disable then re-enable uBlock.

[silverwind]

@gorhill That seemed to fix it. Sorry for not reading the docs :wink:

[gorhill]

Now using Nightly 42.0a1, and really I see uBlock performing very well with it -- as witnessed by about:performance. I ran informal tests to compare against ABP (dev build), an add-on which is similar in purpose (when using uBlock in non-advanced mode). Each tested as the only add-on installed.

• Go to about:performance.
• Set Performance monitor to "2 seconds".

Whereas uBlock typically shows single-digit user (%), ABP is typically reported with 2 digits -- even 3 digits -- for user (%):

• Very simple Hacker News: uBlock = 1%, ABP = 10%.
• Your example Amazon page: uBlock = 8%, ABP = >80%.
• Your opal/opal GitHub issue 942: uBlock = 12%, ABP = 300-400%.
• CNN front page: uBlock = 5%, ABP = >200%.

The only synchronous messaging used by uBlock is a very lightweight one, i.e. there is virtually no waiting time^[1], and in all likeliness, whatever waiting time there is as a result of Firefox synchronous messaging overhead. uBlock could easily switch to asynchronous messaging IF ever there is API documentation which states that whatever async message is guaranteed to be processed before an HTTP observer is called. But there is no such documentation, and although I verified it seems to work in Nightly, I can't write code which relies on wishful thinking -- especially as in its current state uBlock perform excellently compared to similarly purpose add-ons.

---

[1] content-side a synchronous message is sent to the chrome-side, and chrome-side the only thing happening is to quickly store the received data into a pre-allocated ring buffer and return immediately. So the synchronous messaging event is for all practical purpose a non-issue here.

[silverwind]

:clap: Thanks for the results. Love your work!