Message227576
| Author |
scoder |
| Recipients |
georg.brandl, mark.dickinson, python-dev, rhettinger, scoder, serhiy.storchaka |
| Date |
2014年09月25日.21:06:12 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1411679172.29.0.618615574108.issue22464@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Sorry for reopening this, but I found one more thing. Division is pretty heavy on PyLong objects and there doesn't seem to be an internal optimisation for division by 1 and -1. Since many Fraction input values can already be normalised for some reason, the following change shaves off almost 30% of the calls to PyNumber_InPlaceFloorDivide() in the telco benchmark during Fraction instantiation according to callgrind, thus saving 20% of the CPU instructions that go into tp_new().
Instead of always executing
numerator //= g
denominator //= g
this avoids unnecessary divisions:
if g is not 1:
if g is -1:
numerator = -numerator
denominator = -denominator
else:
numerator //= g
denominator //= g
Using the "is" operator here is CPythonish, but doing the same with != and == should also be an improvement already, although not as cheap. Now, given that CPython caches small integers internally, I would suggest actually not adding these two special cases to the fractions module but more generally to the division routines in longobject.c. |
|