The Official 20170730 builds are out

[Anleck]

Disabling cosmetic filtering on the site is enough - thanks gorhill

[gorhill]

I had to look closer at what the benchmark was doing and where was uBO most put under stress.

Turns out there is a pathological case in that benchmark which you will likely never see in the real world, and which account for a significant part of the slowdown. The problem is with the jQuery framework benchmark. This specific benchmark causes the browser to report over 5000 mutated nodes to uBO's mutation observer -- and this is post-coalescing all the mutation events (uBO coalesces these events for efficiency purpose).

Roughly, my understanding of the benchmark is that 100 list items are created, then modified with a new class applied to them, and then removed from the DOM, all this as fast as possible. Somehow with the jQuery framework, this causes over 5000 distinct nodes to be reported to uBO as having been added. This is not a browser issue, I observed this with Chromium too. There is no way this sort of scenario would happen in the real world.

I can add one line to uBO's content script to make uBO look much better on that SpeeDOMeter benchmark. Once I added the line, results showed a single digit percent decrease in performance (~6-8%) compared to when no extension is used on Nightly. But as said, adding that one line I do not expect uBO to benefit any actual performance improvement in the real world, except for that one benchmark, there is just no actual site out there that does what that one benchmark does -- the purpose of the benchmark is strictly to measure one specific thing, not to be a real actual application.

To further emphasize how disconnected it this from real world cases which uBO has to deal with, the benchmark constantly destroy and recreate iframe elements from within which it performs its measurements. This means uBO's own backoff code regarding generic cosmetic filtering never kicks in, again something which does occur with real world cases (uBO measures and detect when generic cosmetic filtering is becoming too expensive and stops surveying the DOM in such case when it repeatedly fails to find matching generic cosmetic filters -- something beneficial for long-lived web page such as Youtube, Gmail, etc.)

In short, any extension listening to DOM mutation events while on that benchmark page will likely perform poorly -- because of these 5000+ mutations events reported during the jQuery framework benchmark -- but then these extensions are probably just doing all fine in the real world.

[streetwolf]

Thanks Ray for delving into the Speedometer issue. I suspected that you would be curious as to what SoM was doing. As I stated in an earlier post I have two other add-ons that cause a decrease in my SoM score. The add-on that produces the biggest hit is Zoom Page WE. From what you discovered regarding uBO is the same sort of thing affecting ZP WE and my other affected add-on?

[gorhill]

The add-on that produces the biggest hit is Zoom Page WE.

I installed this extension and opened the debugger, and I confirm that it does indeed install a mutation observer for childList/subtree, just as with uBO. Again, there is nothing wrong with the Zoom Page WE extension[1], it's the way the benchmark is designed, when a mutation observer for childList/subtree is installed, the benchmark ends up measuring the javascript code handling mutation events -- i.e. spurious measurement since it's not the primary purpose of the benchmark.

Note: above I wrote 5,000+ mutation events, but it's actually more than this, I have also seen 10,000+.

[1] Though a) it would certainly benefit not using a local anonymous function each time it processes a new batch of mutation events; b) coalescing would help -- it's probably because of these two points performance is most affected.

[GHM113]

The most part of the addons I used turned out to be very poorly optimized including AdBlock Plus so I hope WebExtensions API will allow to forget about performance regressions caused by poorly written extensions. It looks addons written by gorhill including uBlock Origin and uMatrix are the only extensions in Mozilla repository that are exceptionally well optimized. They are basically optimized up to the point when there is nothing left to optimize.

Also, I was very surprised when I found out NoScript used synchronous API for content blocking that causes performance problems. Once uMatrix WebExtension is released on AMO, I'll switch to it. I am sure I'll see performance improvements compared to NoScript.

[Josa]

This thread is closed, please use the next one.