New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: enable compiler optimizations when building Python in debug mode #89278
Comments
The Visual Studio project of Python, PCBuild\ directory, disables compiler optimizations when Python is built in debug mode. It seems to be the default in Visual Studio. Disabling compiler optimizations cause two kinds of issues:
Example of test_marshal: # The max stack depth should match the value in Python/marshal.c.
# BUG: https://bugs.python.org/issue33720
# Windows always limits the maximum depth on release and debug builds
#if os.name == 'nt' and hasattr(sys, 'gettotalrefcount'):
if os.name == 'nt':
MAX_MARSHAL_STACK_DEPTH = 1000
else:
MAX_MARSHAL_STACK_DEPTH = 2000 I propose to only change the compiler options for the pythoncore project which builds most important files for the Python "core". See attached PR. |
This change is motivated by my PR 28128 which converts the Py_TYPE() macro to a static inline function. The problem is that by default, MSC disables inlining and test_exceptions does crash with a stack overflow, since my change increases the usage of the stack memory: see bpo-44348. By the problem is wider than just Py_TYPE(). See also bpo-45094: "Consider using __forceinline and __attribute__((always_inline)) on static inline functions (Py_INCREF, Py_TYPE) for debug builds". |
I recently documented the "Python debug build": |
I strongly disagree. If CI needs to be faster, please just change the CI configuration. If contributors have to wait a few minutes longer, they can wait - they'll save that time in local compilations. Local debugging absolutely relies on debug builds. You'd be destroying the workflow of most Windows-based developers with this change. It's not worth it. |
Steve:
Ok, I reject my issue. I found a portable way to fix bpo-44348: it doesn't depend on the OS, nor the compiler, nor compiler options. The fix is to use the trashcan mecanism in the BaseException deallocator: commit fb30509. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: