Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

brave.com

Post reply on HN
Print view View original

181–190 of 289 posts

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#181

Post by avazhi »

jorvi wrote: post #154
avazhi wrote: post #136

Brave also installed a VPN an a VPN service without permission on my Windows machine, and then didn’t disable or remove 3 separate scheduled tasks in Windows Scheduler once I’d uninstalled it. The VPN issue was open for like 8+ months on GitHub too - and at first they denied doing it at all. For all I know it still installs it, but I removed this malware-type shit when this all happened so I couldn’t tell you. I’ll n…

You've commented this three (?) times under this HN post and several times on this site now. Sure seems like you have a bone to pick. The VPN they installed was disabled and they could not activate it without user interaction. And the only reason they did this is so when you click "activate VPN" in the browser, it works immediately. On top of that, other businesses employ(ed) similar tricks. For years and years and y…

Minimising a browser installer surreptitiously installing an unrelated network service without my consent in the name of convenience and then pulling out a whataboutism that has nothing to do with this. Not even gonna bother reading the rest of your comment.

And yeah, my bone to pick is warning others not to fall for Brave’s slick PR. Companies that act that way can pay the price.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#183

Post by mikkupikku »

morshu9001 wrote: post #80
moscoe wrote: post #12

Earlier quoted context omitted.

Now multiply that across all apps/services/extensions/profiles and it adds up. This kind of lazy thinking is why today’s software is so bloated and slow.

It's just Brave browser, you don't multiply by the number of every kind of service

With your attitude towards improving one piece of software, it becomes every piece of software.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#184

Post by mikkupikku »

awnird wrote: post #21

Does Brave actually block ads now? Or does it still replace them with ads for scanmy cryptocurrency?

It's incredible how people can hallucinate nonsense like this out of nothing, simply because their hatred for Brendan Eich drives them insane.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#185

Post by db48x »

hu3 wrote: post #176
wodenokoto wrote: post #115

Earlier quoted context omitted.

So brave has two CSS engines? One for rendering and one for blocking?

Yes. Since for blocking you can afford to have a less mature CSS engine. A tradeoff for performance.

Also the filters for adblocking have extended the CSS selector syntax to add extra features, and you might not want those to leak into your parser for stylesheets.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#186

Post by rollcat »

pezezin wrote: post #158
shatsky wrote: post #96

Earlier quoted context omitted.

And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…

In any modern OS with CoW forking/paging, multiple worker processes of the same app will share code segments by default.

COW on fork has been a given for decades.

You can't COW two different libraries, even if the libraries in question share the source code text.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#187

Post by 0xdeafbeef »

johncolanduoni wrote: post #135
terafo wrote: post #100

Earlier quoted context omitted.

Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be update…

The system you’re proposing wouldn’t work, because without additional effort in the compiler and linker (which AFAIK doesn’t exist) there won’t be perfectly identical pages for the same static library linked into the same executable. And once you can update them independently, you have all the drawbacks of dynamic libraries again. Outside of embedded, this kind of reuse is a very marginal memory savings for the overa…

Also, won't most of the lib be removed due to dead code elimination? And used code will be inlined where applicable, so nothing to dedup in reality

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#188

Post by jeffreygoesto »

ThierryBuilds wrote: post #143
antonok wrote: post #107

Earlier quoted context omitted.

FlatBuffers was definitely the majority of the improvements here! On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.

Insightful. Many thanks. Flat buffers is know to bloat client code. Was any trick used to mitigate that?

The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#189

Post by goku12 »

johncolanduoni wrote: post #134
shatsky wrote: post #101

Earlier quoted context omitted.

It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.

Rust ABI (as opposed to C ABI) dynamic libraries are incredibly fragile with regard to compiler/build environment changes. Trying to actually swap them out between separate builds is pretty much unsupported. So most of the benefits of dynamic libraries (sharing code between different builds, updating an individual dependency) are not achieved. They’re only really useful if you’re distributing multiple binary executab…

Rust does support C ABI through cdylib (as opposed to the unstable dylib ABI). This is used widely, especially for FFI. An example of this is Python modules in Rust using PyO3 [1].

[1] https://pyo3.rs/v0.15.1/#using-rust-from-python

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#190

Post by goku12 »

undeveloper wrote: post #142
shatsky wrote: post #101

Earlier quoted context omitted.

It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.

the rust abi is explicitly unstable. there are community projects to bring dynamic linking, but it's mostly not worth it.

That is not correct. Dynamic linking is natively supported in Rust. How else do you make modules for scripting languages like Python (using PyO3) [1]? It uses the stable C API (cdylib).

[1] https://pyo3.rs/v0.15.1/#using-rust-from-python

Post reply on HN