-
Notifications
You must be signed in to change notification settings - Fork 110
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
Add a benchmark for endoding/decoding #24
Comments
I am working on a set of |
Some updates... adding So for the initial PR I guess I'll just come up with a small set of test cases that make sense to me. If anyone disagrees with the above or has any requests for specific benchmarks, please respond here. :) |
That plan sounds great; thanks for taking this on! Eventually we should test the effect of proto-lens putting all fields in a single, immutable, flat Haskell record. For large protos my guess is it's significantly less efficient (in particular, for decoding) than languages which can do updates by mutating a single field. The standard benchmark might help us examine that use case. |
Closing since the current set of benchmarks has proven useful so far. If we run into any particular bottlenecks in the future, we can add more specific benchmarks as needed. |
We should have a benchmark for encoding to/from the wire format, to make sure that our reflection and abstraction in the parser doesn't cause a significant slowdown compared to other Haskell code, and to give us more confidence when refactoring. (So far, we haven't done any performance tuning of the code.)
One arbitrary data point: decoding a 1MB proto took ~60ms on my desktop, and decoding followed by encoding (which includes forcing all the fields) took ~230ms. (The code was compiled with -O2.)
We should probably also benchmark the text format, though that's usually less performance-critical.
The text was updated successfully, but these errors were encountered: