[tijsvd]

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.