On Sun, 8 Jul 2018 00:14:13 +1000 Nick Coghlan email@example.com wrote:
So, let us gather the requirements for a new calling API.
Here are my starting suggestions:
- The new API should be fully backwards compatible and shouldn't break the
ABI 2. The new API should be used internally so that 3rd party extensions are not second class citizens in term of call performance. 3. The new API should not prevent 3rd party extensions having full introspection capabilities, supporting keyword arguments or another feature supported by Python functions. 4. The implementation should not exceed D lines of code delta and T lines of code in total size. I would suggest +200 and 1000 for D and T respectively (or is that too restrictive?). 5. It should speed up CPython for the standard benchmark suite. 6. It should be understandable.
I like points 1, 2, 3, and 6, but I think point 4 should be a design trade-off rather than a requirement, since minimising the delta in CPython becomes an anti-goal if the outcome of doing so is to make the change harder to adopt for third party projects (at the same time, a delta that's too large is unlikely to be accepted, reviewed and merged, which is what makes it a trade-off).
I don't think point 5 is a goal here either, as the problem isn't that these calling optimisations don't exist, it's that they don't currently have a public API that third party projects can access (the most recent METH_FASTCALL thread covers that pretty well).
Agreed. The goal is not to speed up CPython but to bring third-party extensions up to speed (both literally and figuratively).