Stefan Behnel <stefan...@behnel.de> added the comment: Just FYI and as further motivation, I reimplemented this dedicated parser for quicktions (in Cython, so the timings and speedups are not comparable).
https://github.com/scoder/quicktions/commit/cc034e07325ec492decdb7b1bcca69246cc780fd I was able to get another quite visible improvement by caching the values of "10 ** shift" for 0 <= shift < 58 in a tuple. Higher values are very unlikely in practice, and the memory size of a tuple with 58 values gives a nice multiple of the usual cache line size. (I originally stored 64 values in my commit but then cut it down later.) https://github.com/scoder/quicktions/commit/c20add53dc4936d70eb0daa370946a600adddca9 I suspect that the difference won't be as big for the Python implementation, but it still seems worth a try. The overall speedup that I got, compared to the initial regex implementation, is 50-70%. [regex] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")' 200000 loops, best of 5: 1.19 usec per loop [native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")' 500000 loops, best of 5: 593 nsec per loop [regex] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")' 100000 loops, best of 5: 2.3 usec per loop [native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")' 500000 loops, best of 5: 667 nsec per loop It could be even higher if I additionally moved the int() integer parsing into Cython. Might try that at some point. But that's also not something that concerns the implementation in CPython. ---------- versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28716> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
