In Rust we trust: Brave smashes speed limit after rewriting ad-block engine in super-lang

Software engineers working on the Brave browser have rewritten the browser's ad blocking engine in Rust and seen massive speed increases as a result.

In a blog post on Wednesday, Brave Software performance researcher Andrius Aucinas and chief scientist Ben Livshits said that rewriting Brave's built-in ad blocker in Mozilla-spawned Rust resulted in an average 69x improvement in the amount of time required to process web requests.

The previous iteration of its ad blocking engine was already optimized C++. The speed up was mainly due to algorithmic changes with the added bonus of Rust's low overhead and memory safety.

Rust, a next-gen C/C++-like systems language designed to be fast, safe, and secure, recently celebrated four years in official release and, for each of those years, it has been the most loved programming language in Stack Overflow's annual developer survey.

"Rust gives memory and data-race static (at compile time) safety with native code performance, vs C++," Brave CEO Brendan Eich explained to The Register via email.

"Although most users are unlikely to notice much of a difference in cutting the ad-blocker overheads, the 69x reduction in overheads means the device CPU has so much more time to perform other functions," said Aucinas and Livshits, who observe that the revised engine's deeper browser integration means less duplicative work and the ability to support more blocking rules.

Someone tell Google please

Brave's engine revision arrives as its Chromium foundation is being retrofitted with alternative APIs to make the Chrome extension ecosystem more secure. This change, known as Manifest v3, is expected to come at some cost, however.

The powerful synchronous webRequest API is due to be restricted to enterprise environments, which will affect content blocking, privacy and other extensions that rely on the ability to intercept web requests to determine if they're wanted.

Google says it wants to improve Chrome extension security, privacy and speed but hasn't yet provided complete details of its plan. A preview version of the revised APIs could appear in Chrome's Canary build for developers as soon as the end of July.

Google has defended its plan by claiming there's a performance hit that comes from processing large numbers of network requests in Chrome – ad blockers checks these requests against large lists to determine what should not be let through.

According to Aucinas and Livshits, this isn't an issue for Brave because "requests are processed natively, deep within the browser’s network stack."

Nonetheless, they say they rebuilt Brave's ad blocking engine, moving to an approach inspired by uBlock Origin and Ghostery. They claim they've reduced average request processing time down to 4.6μs (0.0046ms). A recent benchmark test conducted by Cliqz and Ghostery put the average request processing time for the Ghostery extension at 7μs (0.007ms). In that test, Brave's median request processing time took 41μs (0.041ms).

For those using Chrome extensions in Brave, browser performance improvements might matter less if Google's API changes required extension authors to revise their code. But late last month, CEO Brendan Eich said Brave intends to maintain backward compatibility with webRequest.

According to the company, Brave currently has seven million monthly active users. ®