Comment by gorhill | Hacker News Reader

Comment by gorhill | Hacker News Reader

Parent Full thread

> That means that when you are running ublock origin your browser is working at 87.85% capacity.

No it's not, at this point your are spreading FUD about uBO.

This is a benchmark specialized for one thing, the creation/deletion of DOM nodes, a completely unrealistic scenario in the real world -- web sites do not repeatedly create nodes just to have them deleted as soon as they are inserted, as fast as possible.

uBO's code which deals with the DOM represents a fraction of what uBO needs to do, and yet you extrapolate the benchmark as if it represents all the work uBO does, leading to your nonsensical conclusion.

Here is how uBO compares to other comparable content blockers with an actual real-world scenario, as per recent debugbear benchmark[1] -- it's the least CPU hungry of the bunch: https://twitter.com/gorhill/status/1273263792785326085

Note that the above is a worst-case scenario for content blockers, since this was about loading a page from `example.com`, where nothing is blocked, consequently where a content blocker acts only as an overhead. See reference [1] for a more typical scenario.

* * *

[1] https://www.debugbear.com/blog/2020-chrome-extension-perform...

I don't know what to conclude about ad blocker perf from Speedometer, but it's not just creation/deletion of DOM nodes. It runs multiple implementations of TodoMV using various JS frameworks[1, and performs real operations in the web app. DOM is not the bottleneck. The test stresses many parts of the engine, JS, CSS, HTML, rendering, etc.

Google's V8 team (not the original creators of Speedometer, that was WebKit) did a study of real-world JavaScript and found that it was highly correlated with Speedometer[2]. It's likely to be a good proxy of load time and responsiveness for many web sites, especially ones built with modern JS frameworks.

I don't know why uBlock Origin would slow down Speedometer and I'm actually surprised to hear it's true.

[1] https://browserbench.org/Speedometer2.0/ , click on "about Speedometer [2] https://blog.chromium.org/2017/04/real-world-javascript-perf...

Care to comment about the debugbear benchmarks? Why is the supposed undue overhead as per SpeeDOMeter not showing up in there?

I encourage whoever to actually speculate less and measure page load times from the top 500 Alexa and make the case that uBO is an issue CPU- and memory-wise. I confidently predict that you will find that there is no correlation to the SpeeDOMeter benchmark.

There are other 3rd-party benchmarks out there which also found that uBO does indeed save CPU and memory resources.[1][2][3]

* * *

[1] https://twitter.com/gorhill/status/1246085758580142081

[2] https://twitter.com/adildean/status/936183316134416384

[3] https://www.raymond.cc/blog/10-ad-blocking-extensions-tested...

Alright, cool.

I admire your work, gorhill, I do. However I'm not convinced of your results. Lets go ahead and run some benchmarks. First, would you mind tell me how you can about your results?

I'm specifically interested in your results here: https://www.debugbear.com/blog/2020-chrome-extension-perform...

How did you come about your results? Did you use selenium? Or did you catalog all the data by hand? Also, do you have the data available? I'm going to run the tests myself, and any insight would be appreciated. I would especially appreciate it if you could allow me to review the data you have on hand but I understand if you don't want to provide it.

Also, slightly beside the point but is Raymond.cc your site? Just curious.

Thanks for your help!

> Care to comment about the debugbear benchmarks? Why is the supposed undue overhead as per SpeeDOMeter not showing up in there?

I'm not familiar with what you mean by debugbear benchmarks. If you mean the content linked here: https://twitter.com/gorhill/status/1273263792785326085

Then my explanation would be that these measurements measure different things than Speedometer. CPU time is a power metric, First Contentful Paint is a page load speed metric, memory is a memory metric, none of these are web app responsiveness measurements. All of these data points can be true at the same time!

Personally, I would expect any content blocker that does a lot of blocking to speed up page load, reduce memory use, and save power, because less stuff loads and less stuff gets processed. That any ad blocker would reduce Speedometer score is kind of a surprise to me, but if it's real, I believe it.

I really have no stake in which ad blocker is best or more efficient. I just wanted to clarify what Speedometer does, and why it's a relevant measurement.

Yeah, no. Javascript manipulates the dom exactly as you are describing. In fact, javascript is directly responsible for much of the rendering on the modern web today. Hacker News goes in circles talking about it lately, in fact.

So any page with javascript is going to be slowed down precisely for the reason you are stating.

All you have done is compared a bunch of chrome extensions. Adguard is not an extension. Being faster than all the extensions is like being smartest boy who got held back a grade.

I responded to your claim _"It significantly slows down a webpage rendering"_, and provided 3rd-party evaluation to the contrary when actual real world web pages are used.

You counter with a just-trust-me claim that AdGuard not-the-extension is fastest, no objective evaluation provided -- despite AdGuard the-extension not faring the best among the bunch in actual real-world, independent evaluations.

Well, to be honest, AdGuard not-the-extension technically cannot be the fastest. It does a lot of things to do system-wide blocking - analyzing the connection, passing network packets, parsing protocols, this all adds some overhead. Browser extensions simply don't deal with all that stuff and thus any extension, unless it's really poorly written, is not slower.

Moreover, this is not what we are offering. System-wide blocking is about having more control over your system and not about being the fastest.

Reply on news.ycombinator.com