
Loading…
Sometimes `domain` directive in source filter lists is below real domain as per PSL #188
I found an elegant solution to address the problem here for net request filters. However, this adds two more buckets to be tested for each token of a URL, hence potentially an increase in CPU overhead when testing a net request. I decided to benchmark using reference benchmark to find out how performance is affected with the change. Although I didn't expect anything else than a small overhead increase in testing for each net request, results of my benchmark show he opposite:
µBlock > onBeforeRequest: 0.162 ms (18481 samples)
µBlock > onBeforeRequest: 0.162 ms (18768 samples)
µBlock > onBeforeRequest: 0.162 ms (19081 samples)
µBlock > onBeforeRequest: 0.162 ms (19346 samples)
µBlock > onBeforeRequest: 0.161 ms (19690 samples)
µBlock > onBeforeRequest: 0.161 ms (20013 samples)
µBlock > onBeforeRequest: 0.160 ms (20184 samples)
µBlock > onBeforeRequest: 0.161 ms (20371 samples)
µBlock > onBeforeRequest: 0.161 ms (20532 samples)
µBlock > onBeforeRequest: 0.161 ms (20656 samples)
In my former benchmark which I used as official doc, I measured slightly above 0.170 ms per net request.
It was a long time since I measured this particular part of the code, so not sure which changes in between since then is responsible for the now better performance despite the addition of code paths to fix the current bug. Whatever, no negative impacts for the found solution, I'll keep it.
[PSL = Public Suffix List.]
Instrumenting to detect such case, I get the following at the console:
So the
domaindirective for net and cosmetic filters is not strict, it's more like "hostname suffix".The problem here may account for those cases where users report that not all ads are blocked.
I need to think carefully about how to fix this.