Yury Selivanov added the comment: Thanks, Serhiy,
> But I don't quite understand why it adds any gain. Perhaps, and this is just a guess - the fast path does only couple of eq tests & one call for the actual op. If it's long+long then long_add will be called directly. PyNumber_Add has more overhead on: - at least one extra call - a few extra checks to guard against NotImplemented - abstract.c/binary_op1 has a few more checks/slot lookups So it look that there's just much less instructions to be executed. If this guess is correct, then an LTO build without fast paths will still be somewhat slower. > Is this just due to overhead of calling PyNumber_Add? Then we should test > with other compilers and with the LTO option. I actually tried to compile CPython with LTO -- but couldn't. Almost all of C extension modules failed to link. Do we compile official binaries with LTO? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
