Thread by @gorhill

Too often I hear misinformed statements regarding JS-based content blockers -- worse when made in an authoritative manner.

So here I benchmark uBO's static filtering engine (responsible for enforcing EasyList et al.) with over 820K network filters.

This is the results using the built-in benchmark:
github.com/gorhill/uBlock… (you can try it for yourself).

I get ~11µs/request on average, which is no different than if I had benchmarked with just the default filter lists.

This is uBO's memory footprint with the over 820K network filters after visiting the 30 sites on the front page of HN, and after closing the tabs and leaving the browser idle for a minute.

The REAL arguments against too many filter lists are:

- Higher likelihood of site breakage

- On-disk storage used by the extension (mitigation: uBO uses LZ4 compression on Firefox)

- Extension launch time -- notice in previous tweet the 638 ms delay before uBO was fully ready

Benchmark results on Firefox for Android (hardware performance is what most impact results): ~55 µs/network request.

Note that there is one extra filter list enabled by default on Android, AdGuard Mobile Ads.

To be clear, I benchmarked Firefox for Android with uBO with *default* set of filter lists, not the 820K scenario.

Out of pure curiosity, results on Firefox for Android with the 820K+ scenario.

Filtering performance is unchanged, but there is a performance issue for parsing/compiling a gigantic filter list in Firefox for Android: it warns of slow script -- so don't use overly large lists.