-
Notifications
You must be signed in to change notification settings - Fork 185
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
Implements From<FixedDecimal> for PluralOperands #278
Implements From<FixedDecimal> for PluralOperands #278
Conversation
Pull Request Test Coverage Report for Build c8e4619fedf99f4342f7b2c92ac2b050c4222b81-PR-278
💛 - Coveralls |
2046255
to
555a2cd
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
@zbraniecki Should we also see a benchmark report on the pull request? |
Now that #270 is in, can you update your branch and benchmark FixedDecimal::from_str to power PluralOperands? I'd really like to get rid of the redundant string parsing code in PluralOperands. |
This will allow us to convert FixedDecimal representation without loss of precision into PluralOperands, for correct plural selection. For example, a number `25` may sometimes be pluralized differently from `25.0`. Added the benchmarks for the conversion, though without a baseline it is not just as useful yet. (Until we try to reimplement.) See issue unicode-org#190.
We needed to add a custom implementation for eq() to account for loss of precision in PluralOperands.
It is possible to compute it based on the low end of the magnitude range. No performance change per benchmark.
Defines new tests for the data model for conversion, and places them into the JSON files instead of inline with the tests.
This allows criterion to run the benchmark loop with a specific time limit.
Yes, but having done that, the benchmark really isn't happy...
|
6f4f409
to
d0ecb8f
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Helps smoke out specific performance regressions.
I poked at the benchmarks a bit, and added a few tests that tease out individual components of the parsing process. And the results are showing a drastic (~+100%) time increase. From what I can see, the main reason for the slowdown is using We could play some code golf and factor out a parser that builds a shared parsing state that is useful for both See benchmark results below to corroborate. Parsing
New parsing of
Converting
|
After discussing on this weeks icu4x meeting, we decided to remove the change that unifies the parsing from string for |
d0ecb8f
to
98d72b4
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
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 have some ideas on how to speed up the conversion function, but let's check this in first so we can get the benchmarks and tests. I'll test some of my ideas then.
This will allow us to convert FixedDecimal representation without loss
of precision into PluralOperands, for correct plural selection.
For example, a number
25
may sometimes be pluralized differently from25.0
.Added the benchmarks for the conversion, though without a baseline it is
not just as useful yet. (Until we try to reimplement.)
See issue #190.