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
Cache the hash value of fractions #96465
Comments
|
See also #58683. The similar patch for Decimal was rejected. |
|
Classic time vs. space trade-off. How common is hashing Fractions? (The example seems a bit special.) If we decide to do this, I'd prefer the version using an LRU cache, so that someone creating a large number of Fractions they aren't hashing doesn't have to pay the price. Did you think about the cache size much or is 65k just your go-to cache size value these days? FWIW the Decimal patch for Python was rejected. The C version seems all right, so the problem would only affect the tiny minority of people who can't use the C Decimal version. So that's not comparable here. |
|
@rhettinger Do you have have benchmark data? |
Baseline% ~/cpython/python.exe -m timeit -s 'from fractions import Fraction as F' -s 'f = F(375, 34)' 'hash(f)' With caching% git checkout fraction_hash_cache |
rhettinger commentedAug 31, 2022
•
edited
In both 3.10 and 3.11, hashing a small fraction is 20x slower than for a decimal. For fractions with large denominators, it is slower still.
We could sacrifice the space for one slot to cache the hash value:
Another approach would be to have a single, size limited cache for the computation:
Example of code that would benefit:
The text was updated successfully, but these errors were encountered: