-
Notifications
You must be signed in to change notification settings - Fork 841
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
Improve decimal parsing performance #3854
Conversation
f094bb5
to
e377d8b
Compare
Thank you for this, will review fully tomorrow. Just some ideas that might make this even faster
|
Thanks for the suggestions. I will have a look the next few days! |
Thank you @spebern -- this looks quite exciting. Do you have any benchmarks you can share for this branch? |
|
I had a look at what @tustvold suggested and in some cases we'd get another ~40% of performance. However, I only tested this for the 128 bit types, because What do you think of replacing the usage of |
These should be relatively straightforward to implement, I will see what I can do
❤️ |
Does it make sense to have a look at Would probably save some work, since all the ops from the rust std lib seem to be implemented there. I will have a look at |
I think if we can avoid a dependency, especially one that doesn't have a clear maintenance story (it is a personal crate), that is better. Let me see what it looks like, I think it should be straightforward. |
Related #3884 |
I had a closer look at I opened Alexhuszagh/rust-lexical#93, because as For now, I see three options for continuing here:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think as is this PR represents a significant performance improvement, we can always further improve the performance in subsequent PRs. Thank you for this
"parse decimal overflow".to_string(), | ||
)); | ||
} | ||
result = result.mul_checked(base)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It occurs to me that the precision check above should mean neither of these can overflow
Which issue does this PR close?
Rationale for this change
Improve decimal parsing performance (~50%)
What changes are included in this PR?
Are there any user-facing changes?