[saagarjha]

I read the article the quote was pulled from, as well as participated in the discussion and responded to the author when it was posted here. Just FYI, Safari (which already has this feature in the form of content blockers) is able to block ads just fine, and anecdotally the performance is slightly, but noticeably better.

[feanaro]

The question still remains: what are they optimizing for if we already have sub-millisecond response times?

The only evidence you offer is anecdotal. I'm having a hard time imagining perceptible differences in sub-millisecond response times so either you or the study are in error.

And just to reiterate other comments: yes, Safari is probably able to block ads just fine now, because they modeled the engine according to capabilities needed right now. However, it comes at a huge cost to innovation and creates yet another barrier of entry guarded by a large corporation.

Taking all of that in account, it seems unnecessary. The looming threat of ulterior motives from Google remains ever-present.

[saagarjha]

To be honest, I'm much more in favor of this API because of its privacy features than performance. I think it's a little bit faster, but it has a much bigger benefit on the trust side because extensions no longer run arbitrary JavaScript in every page I visit.

[feanaro]

It's very improbable the few popular ad blocking extensions could slide in something sinister and avoid public scrutiny for a long time. You have much more reason to be worried about your privacy from Chrome than from uBlock Origin, since Chrome and Google provably violate it.

[saagarjha]

I don’t use Chrome partially for this reason :)

[ubercow13]

It does not have any privacy benefit. Extensions can still do that

[saagarjha]

They can, but presumably they will be clearly labeled as they are today.

[zuzun]

JavaScript code will take a millisecond to decide whether to block a request or not and some hard-coded browser function will do it slightly faster, but not by much, because most of the work will be done by the same regular expression, so we are talking about fractions of a millisecond here and you claim to notice that?

[saagarjha]

Safari pre-compiles the blocking list into some internal representation that is faster than a raw regular expression, and the matching operation is performed many times per page. So I do think it's possible to notice a small performance benefit?

[zuzun]

To filter URLs, you have to parse them, check if the domain is blocked using a hash table and then search for thousands of substrings in the path and query parts of the URL. If you use a regex for that, most of the filtering will already run in native code. I guarantee you that this gives you a tough to beat baseline with almost no room for improvements.

Looking at the WebKit implementation, the authors are shipping their own regex engine for whatever reason. I doubt that it beats the battle-tested re2 engine by large margins, if at all.

[saagarjha]

I don’t think the content blocker API allows for the full set of features you’d find in standard regex library. This might mean that WebKit can roll their own regex library that’s better optimized for this subset?