Replacing Protobuf with Rust to go 5 times faster

I find the title a bit misleading. I think it should be titled It’s Faster to Copy Memory Directly than Send a Protobuf. Which then seems rather obvious that removing a serialization and deserialization step reduces runtime.

Are they sure it's because Rust? Perhaps if they rewrite Protobuf in Rust it will be as slow as the current implementation.

They changed the persistence system completely. Looks like from a generic solution to something specific to what they're carrying across the wire.

They could have done it in Lua and it would have been 3x faster.

"5 times faster" reminds me of Cap'n Proto's claim: in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers: https://capnproto.org/

Just for fun, how often do regular-sized companies that deal in regular-sized traffic need Protobuf to accomplish their goals in the first place, compared to JSON or even XML with basic string marshalling?

FlatBuffers are already faster than that. But that's not why we choose Protobuf. It's because a megacorp maintains it.

Don't read clickbaity headlines and scan hacker news five times faster.

You should be terrified of the instability you're introducing to achieve this. Memory sharing between processes is very difficult to keep stable, it is half the reason kernels exist.

I don't understand, I used protobuf for map data, but it is a hardcore simple format, this is the whole purpose of it.

I wrote assembly, memory mapping oriented protobuf software... in assembly, then what? I am allowed to say I am going 1000 times faster than rust now???

I vaguely recall that there's a Rust macro to automatically convert recursive functions to iterative.

But I would just increase the stack size limit if it ever becomes a problem. As far as I know the only reason it is so small is because of address space exhaustion which only affects 32-bit systems.

tldr: they replaced using protobuf as the type system across language boundaries for FFI with true FFI