2016-08-09 0:40 GMT+02:00 Guido van Rossum <gu...@python.org>: > Hm, I agree that those tuples are probably expensive. I recall that > IronPython boasted faster Python calls by doing something closer to the > platform (in their case I'm guessing C# or the CLR :-).
To be honest, I didn't expect *any* speedup just by avoiding the temporary tuples. The C structore of tuples is simple and the allocation of tuples is already optimized by a free list. I still don't understand how the cost of tuple creation/destruction can have such "large" impact on performances. The discussion with Larry was not really my first motivation to work on FASTCALL. I worked on this topic because CPython already uses some "hidden" tuples to avoid the cost of the tuple creation/destruction in various places, but using really ugly code and this ugly code caused crashes and surprising behaviours... https://bugs.python.org/issue26811 is a recent crash related to property_descr_get() optimization, whereas the optimization was already "fixed" once: https://hg.python.org/cpython/rev/5dbf3d932a59/ The fix is just another hack on top of the existing hack. The issue #26811 rewrote the optimization to avoid the crash using _PyObject_GC_UNTRACK(): https://hg.python.org/cpython/rev/a98ef122d73d I tried to make this "optimization" the standard way to call functions, rather than a corner case, and avoid hacks like PyTuple_SET_ITEM(args, 0, NULL) or _PyObject_GC_UNTRACK(). Victor _______________________________________________ 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
