Author vstinner
Recipients lemburg, mark.dickinson, methane, rhettinger, serhiy.storchaka, vstinner
Date 2017-02-15.17:27:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> # 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)?
Date User Action Args
2017-02-15 17:27:01vstinnersetrecipients: + vstinner, lemburg, rhettinger, mark.dickinson, methane, serhiy.storchaka
2017-02-15 17:27:01vstinnersetmessageid: <>
2017-02-15 17:27:01vstinnerlinkissue29548 messages
2017-02-15 17:27:01vstinnercreate