Stefan Behnel added the comment:
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.
----------
status: closed -> open
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22464>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
