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

Replacing Protobuf with Rust

pgdog.dev

Post reply on HN
Print view View original

71–80 of 135 posts

Re: Replacing Protobuf with Rust

#71

Post by infogulch »

cranx wrote: post #32

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.

Why don't we use standardized zero-copy data formats for this kind of thing? A standardized layout like Arrow means that the data is not tied to the layout/padding of a particular language, potential security problems like bounds checks are automatically handled by the tooling, and it works well over multiple communication channels.

Re: Replacing Protobuf with Rust

#72

Post by cmrdporcupine »

MrDarcy wrote: post #47
cranx wrote: post #32

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.

TIL serializing a protobuf is only 5 times slower than copying memory, which is way faster than I thought it’d be. Impressive given all the other nice things protobuf offers to development teams.

I wouldn't hold onto that number as any kind of fixed usable constant since the reality will depend entirely on things like cache locality and concurrency, and the memory bandwidth of the machine you're running on.

Go around doing this kind of pointless thing because "it's only 5x slower" is a bad assumption to make.

Re: Replacing Protobuf with Rust

#73

Post by formerly_proven »

logicchains wrote: post #58
GuB-42 wrote: post #57

What I find particularly ironic is that the title make it feel like Rust gives a 5x performance improvement when it actually slows thing down. The problem they have software written in Rust, and they need to use the libpg_query library, that is written in C. Because they can't use the C library directly, they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. Problem is that it is slo…

> they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. That sounds like a performance nightmare, putting Protobuf of all things between the language and Postgres, I'm surprised such a library ever got popular.

> I'm surprised such a library ever got popular.

Because it is not popular.

pg_query (TFA) has ~1 million downloads, the postgres crate has 11 million downloads and the related tokio-postgres crate has over 33 million downloads. The two postgres crates currently see around 50x as much traffic as the (special-purpose) crate from the article.

edit: There is also pq-sys with over 12 million downloads, used by diesel, and sqlx-postgres with over 16 million downloads, used by sqlx.

Re: Replacing Protobuf with Rust

#74

Post by suriya-ganesh »

This is an unfair comparison.

using a transport serialization and deserialization protocol for IPC. It is obvious why there was an overhead because it was architectural decision to manage the communication.

I guess the old adage of if something goes 20% faster something was improved if it is 10x faster, it was just built wrong is true here.

Re: Replacing Protobuf with Rust

#75

Post by vlovich123 »

the__alchemist wrote: post #62
GuB-42 wrote: post #57

What I find particularly ironic is that the title make it feel like Rust gives a 5x performance improvement when it actually slows thing down. The problem they have software written in Rust, and they need to use the libpg_query library, that is written in C. Because they can't use the C library directly, they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. Problem is that it is slo…

I wonder why they didn't immediately FFI it: C is the easiest lang to write rust binding for. It can get tedious if using many parts of a large API, but otherwise is straightforward. I write most of my applications and libraries in Rust, and lament that most of the libraries I wish I would FFI are in C++ or Python, which are more difficult. Protobuf sounds like the wrong tool. It has applications for wire serializati…

It’s trivial to expose the raw C bindings (eg a -sys crate) because you just run bindgen on the header. The difficult part can be creating safe, high-performance abstractions.

Re: Replacing Protobuf with Rust

#76

Post by notyourwork »

7e wrote: post #44
Sesse__ wrote: post #31

Earlier quoted context omitted.

> I mean, cap'n'proto is written by the same person who created protobuf Notably, Protobuf 2, a rewrite of Protobuf 1. Protobuf 1 was created by Sanjay Ghemawat, I believe.

Google loves to reinvent shit because they didn't understand it. And to get promo. In this case, ASN.1. And protobufs are so inefficient that they drive up latency and datacenter costs, so they were a step backwards. Good job, Sanjay.

Really dismissive and ignorant take from a bystander. Back it up with your delivery that does better instead of shouting with a pitchfork for no reason.

Re: Replacing Protobuf with Rust

#77

Post by vlovich123 »

bluGill wrote: post #56
cranx wrote: post #32

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.

Protobuf does something important that copying memory cannot do: a protocol that can be changed separately on either end and things can still work. You have to build for "my client doesn't send some new data" (make a good default), or "I got extra data I don't understand" (ignore it). However the ability to upgrade part of the system is critical when the system is large and complex since you can't fix everything to u…

But something more modern that doesn’t have the encoding/decoding penalty of Protobuf would be better (eg cap’n’proto but there’s a bunch now in this space).

Re: Replacing Protobuf with Rust

#78

Post by 9rx »

tuetuopay wrote: post #33
t-writescode wrote: post #18

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?

Type safety. The contract is the law instead of a suggestion like JSON. Having a way to describe your whole API and generate bindings is a godsend. Yes, it can be done with JSON and OpenApi, yet it’s not mandatory.

> Yes, it can be done with JSON and OpenApi, yet it’s not mandatory.

It is not mandatory for Protobuf either. You can construct a protobuf message with an implied structure just as you can with JSON. It does not violate the spec.

Protobuf ultimately gets the nod because it has better tooling (which isn't to be taken as praise towards Protobuf's tooling, but OpenAPI is worse).

Re: Replacing Protobuf with Rust

#79

Post by dchuk »

GuB-42 wrote: post #57

What I find particularly ironic is that the title make it feel like Rust gives a 5x performance improvement when it actually slows thing down. The problem they have software written in Rust, and they need to use the libpg_query library, that is written in C. Because they can't use the C library directly, they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. Problem is that it is slo…

Given they heavily used LLMs for this optimization, makes you wonder why they didn’t use them to just port the C library to rust entirely. I think the volume of library ports to more languages/the most performant languages is going to explode, especially given it’s a relatively deterministic effort so long as you have good tests and api contracts, etc

Re: Replacing Protobuf with Rust

#80

Post by [deleted] »

linuxftw wrote: post #51

Many people are exclaiming that the title is baity, but I disagree. It seems like a perfectly fine title in the context of this blog, which is about a specific product. It's unlikely they wrote the blog with a HN submission in mind. They're not a news publication, either.

[deleted]
Post reply on HN