-
Notifications
You must be signed in to change notification settings - Fork 107
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
Use specific builder functions for encoding. #187
base: master
Are you sure you want to change the base?
Conversation
Please add some performance numbers to the pull request. |
Instead of keeping internal function for decoding we can reuse much more efficient builders from the bytestring library. It increases speed and improves memory usage and allows more code sharing between the libraries. Specialization pragmas were removed, they didn't provide much benefit anyway as the code is recursive and optimizer does not inline it. However internal functions were not removed so the user of cassava can use them for semi-efficient numeric types encoding in case if there are no efficient builders available directly for those types.
before the patch:
After the patch:
should I include that in the patch content itself? Actually for float, and double it gives worse result. So I've exclude it from the patch for now. |
I'll let @hvr decide. For me just having the numbers somewhere is good (in particular to make sure someone looked at them). |
What was the conclusion of this investigation? I think it would make sense to add QuickCheck tests that demonstrate that the new implementation matches the behavior of the old. Do you think you could add such tests? |
I think I didn't come with a concrete solution, but I can't recall since long time passed.
Yes! I'll do will make them on the weekend in the worst case. |
@qnikst : QuickCheck tests would be great here! |
Instead of keeping internal function for decoding we can
reuse much more efficient builders from the bytestring library.
It increases speed and improves memory usage and allows more
code sharing between the libraries.
Specialization pragmas were removed, they didn't provide much
benefit anyway as the code is recursive and optimizer does not
inline it. However internal functions were not removed so the
user of cassava can use them for semi-efficient numeric types
encoding in case if there are no efficient builders available
directly for those types.