Best approach for opaque PyObject
The goal as it stands is to make PyObject an opaque type (interpreted to mean, "incomplete type"), but there is a blocking problem to accomplishing that. Functions/Macros like PY_TYPE require a complete PyObject. There is 3 ways we can solve this problem: 1) Dump to & export from the Python DLL. - This will created performance overhead that can scale worse and worse the more they're used. 2) Dump to a static library. - This has a toss up on saving performance or sharing #1's problem depending on the compiler and options used. 3) Dump to precompiled headers. - My limited understanding of precompiled headers suggests we can eliminate the need of LTCG, but compilers CAN impose restrictions on their usage (MSVC for sure has restrictions). What would be the best approach to go with? Ultimately, the end result should have roughly the same performance rating as current non limited code.
On Thu, Jul 2, 2020, at 16:04, William Pickard wrote:
The goal as it stands is to make PyObject an opaque type (interpreted to mean, "incomplete type"), but there is a blocking problem to accomplishing that.
Functions/Macros like PY_TYPE require a complete PyObject.
Is it acceptable if the performance hit only applies to external [not part of the python implementation] callers? The macro could be defined as to call an exported function from external code but as its current definition within the python implementation. I do think there's a much bigger problem, though... if PyObject is opaque, then extension modules cannot define their own types, since the definition of any extension type has to begin with PyObject_HEAD. It could be replaced by a "semi-opaque" definition of the same size and alignment, but would that solve whatever problem making PyObject opaque is intended to solve?
participants (2)
-
Random832 -
William Pickard