![]() ![]() The new engine already supports more of the filter rule syntax that has evolved beyond the original specification, which will allow us to handle web compatibility issues better and faster.įor performance measurements in this study we used a 2018 MacBook Pro laptop with 2.6 GHz Intel Core i7 CPU and 32GB RAM.With this information already available, our browser-focused API provides still better performance, cutting average request processing time down to 4.6μs. An additional benefit of having the blocker built into the core of the browser is even less work duplicating what the browser already does, e.g.For the popular filter list combination of EasyList and EasyPrivacy it achieves class-leading performance of spending only 5.7μs on average per request.The new algorithm with optimised set of rules is 69x faster on average than the current engine.We implemented the new engine in Rust as a memory-safe, performant language compilable down to native code and suitable to run within the native browser core as well as being packaged in a standalone Node.js module. This focuses on a tokenization approach specific to ad-block rule matching against URLs and rule evaluation optimised to the different kinds of rules. We therefore rebuilt our ad-blocker taking inspiration from uBlock Origin and Ghostery’s ad-blocker approach. Out of the 242,944 requests, 39% were blocked when using the popular combination of EasyList and EasyPrivacy. We reused the dataset from Cliqz ad-blocker performance study that collected requests across top 500 domains and up to 3 pages of each domain. Alas, blocked trackers are not that uncommon. ![]() It used the Bloom Filter data structure that tracks fragments of requests that may match and quickly rule out any that are clean. Our previous algorithm relied on the observation that the vast majority of requests are passed through without blocking. the more generic ones matching arbitrary patterns within a URL require more involved matching than a simple string search Complexity of a rule being evaluated, e.g.how many rules need to be checked without a match before a matching one is found Number of rules that need to be checked before a request is blocked or accepted, e.g.phone or laptop) speed, the key factors that affect request processing time are: Nevertheless, the argument of the popular ad-blockers being very efficient made by our friends at Cliqz also pointed out that ours could be made faster still.īrave’s network request ad-blocker supports Adblock Plus (“ABP”) filter syntax and we have previously looked at how the cost of ad-blocking adds up with the popular ad-blocking lists growing, often without the rules actually being used. The recent Chromium’s Manifest v3 controversy around the overheads of the various extensions using the WebRequest API to inspect and potentially block undesired requests did not affect Brave as requests are processed natively, deep within the browser’s network stack. Starting today, this new implementation is available in our Dev channel and Nightly channel. Even though Brave’s ad-blocker was already implemented in heavily optimized C++ handling requests with sub-millisecond overhead, we found that we can further optimise it for a 69x average improvement. Since loading an average website involves 75 requests that need to be checked against tens of thousands of rules, it must also be efficient. Ben Livshits, Brave’s Chief Scientist.īrave Shields, which protect users’ privacy from trackers and ads, are one of the cornerstone components of the browser involved in handling every single web request made for loading a website. Andrius Aucinas, performance researcher at Brave, and Dr. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |