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
Keeping an account of allocated blocks slows down _PyObject_Malloc() and _PyObject_Free() by a measureable amount. Have _Py_GetAllocatedBlocks() iterate over the arenas to sum up the allocated blocks for pymalloc.
Surprising! Good catch. I doubt this function is ever used outside of memory-leak detectors, so its speed is hard to care about. I'm just asking for a change to round the arena base address up to the first pool's actual address (which probably isn't really needed on Linux or Windows, but will be needed if pool sizes ever increase beyond the OS page size).
|
When you're done making the requested changes, leave the comment: |
|
I have made the requested changes; please review again |
|
@nascheme: Please replace |
…on#14680) Keeping an account of allocated blocks slows down _PyObject_Malloc() and _PyObject_Free() by a measureable amount. Have _Py_GetAllocatedBlocks() iterate over the arenas to sum up the allocated blocks for pymalloc.
…on#14680) Keeping an account of allocated blocks slows down _PyObject_Malloc() and _PyObject_Free() by a measureable amount. Have _Py_GetAllocatedBlocks() iterate over the arenas to sum up the allocated blocks for pymalloc.
Keeping an account of allocated blocks slows down _PyObject_Malloc() and _PyObject_Free() by a measureable amount. Have _Py_GetAllocatedBlocks() iterate over the arenas to sum up the allocated blocks for pymalloc.
https://bugs.python.org/issue37537