The README mentions it's "significantly faster than protobufs (Prost implementation)", but also mentions that the wire format is pretty similar. This makes me wonder: why would you want to use this over Protobuf? Protobuf has a larger ecosystem, and support for many other programming languages.
I can imagine that if you're able to outperform Prost using a similar wire format, there must also be a way to bring Prost up to par, or to design an alternative Protobuf implementation that's faster.
(Sorry if the above sounds a bit too negative; I'm just trying to figure out what the value is.)
I was generally OK with the speed of Prost, and making it faster was not the goal really. The goal was to make the generated code more Rust-friendly.
It is probably faster due to straightforward decoding, no tag switch. At the cost of not being able to reorder fields or remove in the middle.
With protobuf implementations, one always goes from schema to generated code, which means certain choices can not be handled without further markup:
- what to do with unknown enum values
- which fields become Option
- which string or bytes fields should be by-ref rather than by-value
- derive of other traits
I guess the alternative could have been to build all that into Prost, but that seemed unreasonable. I see this more as a replacement of bincode than as a replacement of Prost.
EdSchouten|4 years ago
I can imagine that if you're able to outperform Prost using a similar wire format, there must also be a way to bring Prost up to par, or to design an alternative Protobuf implementation that's faster.
(Sorry if the above sounds a bit too negative; I'm just trying to figure out what the value is.)
tijsvd|4 years ago
It is probably faster due to straightforward decoding, no tag switch. At the cost of not being able to reorder fields or remove in the middle.
With protobuf implementations, one always goes from schema to generated code, which means certain choices can not be handled without further markup:
- what to do with unknown enum values
- which fields become Option
- which string or bytes fields should be by-ref rather than by-value
- derive of other traits
I guess the alternative could have been to build all that into Prost, but that seemed unreasonable. I see this more as a replacement of bincode than as a replacement of Prost.