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
Comparing numbers can take a surprising amount of time #125
Comments
Yeah that can be done. |
PartialEqual has a "scale difference" issue, too:
Where that subtraction could cause an out-of-memory error allocating 10^(terabyte-sized-number) (and by terabyte I mean exabyte.....) |
Oh no, that was the old version. It was fixed in September. I probably meant to fix |
Implementation is ready, and I included your example test. I'd like to write a few more tests to improve the coverage. It now tries to cast the big ints to u64, then u128, then creates Vec of the digits, so the amount of memory required is only dependent on number of digits, not the scale. And no allocations if the value is under 40 digits long. |
I'm calling it for the night, but leaving myself a message: example : I'm not sure what to do in that case. I would guess that it's safe to assume they're not equal, as that would mean exabytes of numbers to reach equality, and go with less Less/Greater base on which scale is larger. |
That was fixed with a new |
Testing at the boundaries here lead to finding a similar panic in implementation of |
Now the hard part is making contrived test cases which avoid the optimizations. |
I'm happy with result. It's now merged into trunk in commit b34622d. Let me know if that works for you. |
Fantastic! It works great :D |
I understand that comparing numbers that are very similar might take a bit of time, as it might need to read all stored digits in the worst case. But certainly there is no expensive computation involved, right?
However, calling
cmp
always has a large overhead in CPU and memory. Example:Note that creating
teenytiny
andone
is very quick: The internalBigInt
and wrappingBigDecimal
require barely any memory at all. However, the comparisons are excruciatingly slow, because:This subtraction effectively runs an infinite loop, even though
cmp
could be determined (for this input) very easily.Implementing some kind of early-return path would be really nice.
Related: uutils/coreutils#3318
The text was updated successfully, but these errors were encountered: