-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimization opportunity: encoded_len
gets computed twice when encoding a message
#1112
Comments
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? |
I would probably go for either introducing a
The million dollar question 😅. 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 👋! 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 🙏
The text was updated successfully, but these errors were encountered: