2 ms·
Think about it from a mathematical perspective: How much CPU time is actually spent evaluating ad blocker rules? It's going to be proportional to the number of
by kevingadd 4y ago
Think about it from a mathematical perspective: How much CPU time is actually spent evaluating ad blocker rules? It's going to be proportional to the number of HTTP requests you issue. On a good website the number of requests is in the dozens or a hundred tops per page load, on a bad website maybe it's in the low thousands. But that's it. Let's say you have 300000 rules (I think the actual number tends to be much lower than this), worst case even if you brute forced that, you're evaluating 300000 regexes maybe a thousand times. That'll take some time, but not that much time, because modern CPUs are really fast. It's simply implausible that an ad blocker could have a significant negative impact on battery life unless you wrote it in some sort of forth interpreter that was checking strings one byte at a time - compared to the rule evaluations happening once per request, you're rasterizing frames ~60 times a second and handling input events and timers and all of that stuff constantly.
If you optimize the rules engine - which you can definitely do - you can skip evaluating most of those regexes, you can evaluate them in parallel, etc. You could start preparing the request and only gate the actual tcp packets on approval from the ad blocker. You could cache the approve/deny state for each URL so that the ad blocker overhead is only paid on first visit to a site. There are lots of ways to make this stuff super fast without breaking it, but Google and Apple don't want to do the work.
People like the uBlock Origin author have already demonstrated in the past that their ad blockers are fast despite the severe limitations of current browser extension APIs. If browser vendors actually supported extension developers ad blockers could probably become faster. Instead they're attacking them and forcing people to move over to intentionally sabotaged APIs with limited feature sets and arguing that now things will be "faster" even though you're going to be wasting resources downloading a bunch of ads.