Brave Browser is one of the few major web browsers that supports native content blocking on all supported platforms that is enabled by default. It...
chipp.in
This is basically a “data structure + representation” change: Brave moved its default filter set from normal Rust in-memory objects (lots of small heap allocations) into a compact, mostly read-only binary blob that can be accessed without copying.
What likely changed under the hood (why FlatBuffers helps)
With a typical adblock engine, the default lists (tens or hundreds of thousands of rules) get parsed into structures like vectors, hash maps, strings, regex objects, etc. That usually means:
- Many heap allocations (each allocation has overhead and fragments memory)
- Many duplicated strings / tokens
- Extra copies when building and loading those structures
FlatBuffers is designed to store structured data in a compact binary format that can be “viewed” directly (zero-copy) rather than rebuilt into lots of heap objects. In practice, that can reduce:
- Allocation count
- Per-object overhead
- Pointer-heavy graphs of objects (which are memory-inefficient)
So the “~75% / ~45 MB” claim is plausible specifically for the filter-engine data structures that were previously living as heap-allocated Rust collections.
How the other optimizations fit in
The bullet points you quoted are the “second-order” wins that usually come along once you refactor the core representation:
- Stack-allocated vectors: fewer heap hits during parsing/building; typically improves both memory and build time.
- Tokenizing common regex patterns: reduces expensive regex work and can speed matching (at the cost of extra engineering complexity).
- Sharing resources between engine instances: avoids reloading/re-parsing the same data multiple times (useful if multiple profiles/contexts need an engine).
- Optimized internal storage: often means tighter encoding, deduplication, smaller indices, and less wasted capacity in buffers.
Security / privacy angle (what this does and does not mean)
This is mainly a performance/memory improvement, not a “security breakthrough” by itself. A few practical points:
- Lower memory usage can reduce overall browser pressure (less swapping / fewer slowdowns), which indirectly improves stability.
- It does not automatically mean better blocking, fewer false positives, or stronger anti-tracking. That depends on the rules and matching logic, not only the storage format.
- Any major refactor can introduce regressions. If users notice site breakage or weaker blocking after upgrading, it’s worth reporting to Brave with repro steps and the exact filter setup.
How to validate the claim on your own system (safe, practical checks)
If you want to see whether you personally benefit:
- Confirm you’re on Brave 1.85 (or newer): open brave://version
- Compare memory with the same session/profile and the same filter selections enabled/disabled
- Use Brave’s task manager (Shift+Esc) and/or brave://memory-redirect (Chrome-style memory reporting) to compare before/after
- If you use lots of extra filter lists, test with and without them, since Brave claims larger gains for “additional filters”
Bottom line
Brave’s explanation is consistent with a real-world way to cut memory: reducing heap-heavy in-memory representations and switching to a compact, zero-copy format. The most meaningful “user action” is simply to update to the version where it landed (1.85 per the article) and validate with consistent measurements if memory usage is a concern.
Sources
