Hi, I tried two options to add support for FASTCALL on calling an object: add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall slot. I failed to implement correctly any of these two options.
There are multiple issues with tp_fastcall: * ABI issue: it's possible to load a C extension using the old ABI, without tp_fastcall: it's not possible to write type->tp_fastcall on such type. This limitation causes different issues. * If tp_call is modified, tp_fastcall may be outdated. Same if tp_fastcall is modified. What happens on "del obj.__call__" or "del type.__call__"? * Many public functions of the C API still requires the tuple and dict to pass positional and keyword arguments, so a compatibility layer is required to types who only want to implement FASTCALL. Related issue: what is something calls tp_call with (args: tuple, kwargs: dict)? Crash or call a compatibility layer converting arguments to FASTCALL calling convention? Reusing tp_call for FASTCALL cause similar or worse issues. I abandoned my idea for two reasons: 1) in the worst case, my changes caused a crash which is not accepted for an optimization. My first intent was to removed the property_descr_get() hack because its implementation is fragile and caused crashes. 2) we implemented a lot of other optimizations which made calls faster without having to touch tp_call nor tp_fastcall. The benefit of FASTCALL for tp_call/tp_fastcall was not really significant. Victor 2018-06-18 7:55 GMT+02:00 Jeroen Demeyer <j.deme...@ugent.be>: > On 2018-06-18 03:34, INADA Naoki wrote: >> >> Victor had tried to add `tp_fastcall` slot, but he suspended his effort >> because >> it's benefit is not enough for it's complexity. >> https://bugs.python.org/issue29259 > > > I has a quick look at that patch and it's really orthogonal to what I'm > proposing. I'm proposing to use the slot *instead* of existing fastcall > optimizations. Victor's patch was about adding fastcall support to classes > that didn't support it before. > > > > Jeroen. > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com