STINNER Victor added the comment: > # builtin min and max doesn't support FASTCALL > (...): 1.16x slower (+16%)
Hum, the slowdown is not negligible, even if functools.reduce() is rarely used. Do you think that it would be insane to have two code paths instead? * New FASTCALL path if func suports FASTCALL calling _PyObject_FastCall() * Current code path using cached args tuple otherwise For example, you can use args==NULL marker for the FASTCALL path. Maybe we need a _PyObject_SupportFastCall() function which would return 1 for Python functions and C functions, except of C functions with METH_VARARGS flag set. My expectation is a speedup for functions supporting FASTCALL, but *no slowdown* for functions not supporting FASTCALL. -- property_descr_get() also caches args tuple. I started my work on FASTCALL because this optimization caused bugs (but also because I wanted to make Python faster, but that's a different topic ;-)). In the past, the _pickle module also used cached args tuple, but the cache was removed because it was vulnerable to race conditions. For this issue, I suggest to leave functools.reduce() unchanged, but open a new issue to discuss what to do with code still using a cached args tuple. My long term goal with FASTCALL was to remove completely cached tuple used to call functions. I wrote tp_fastcall for that, but tp_fastcall (issue #29259) was rejected. The rejected tp_fastcall blocked my long term plan, we have to find a different approach. Maybe we should add support for FASTCALL for a little bit more functions, and later simply remove the optimization (hack, cached tuple)? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29548> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
