Open ivoanjo opened 2 months ago
Thanks, that is great that you found this. Do you have a suggestion on how to fix this? Are you willing to create a PR for that?
Thanks, that is great that you found this. Do you have a suggestion on how to fix this?
I would probably go for either introducing a encode_raw_with_len
that receives the len as an argument or modifying the existing encode_raw
to always then the len as an argument (I'm not sure where else it gets used).
Are you willing to create a PR for that?
The million dollar question :sweat_smile:. I'm working on a few other bigger optimizations on our codebase first, and I'm not sure when I'll have enough time to circle back to this one.
So I'll keep it on my radar, but it may take a while -- this is why I decided to report, so it wasn't forgotten/and in case someone wanted to pick it up faster than I can :)
Hey :wave:! I work at Datadog and we use prost in our libdatadog rust component.
While looking at some performance profiling of our protobuf encoding, I noticed that there's quite a bit of repeated work between
encode
andencode_raw
since both needencoded_len
, and it gets computed twice:Specifically,
Message::encode
computes theencoded_len
to check if the buffer has enough space, and then throws this info away, and thenencode_raw
gets the number again as it needs to record the field size in the pprof.Computing
encoded_len
is around 5% of the time of this benchmark, so there would be a nice gain in encoding speed if it was computed only once.We're happy users of prost so I decided to report this in the spirit of "see something, say something".
Thanks again for your amazing work so far :pray: