Author vstinner
Recipients njs, pitrou, vstinner
Date 2016-03-11.17:52:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1457718771.98.0.98972359451.issue26530@psf.upfronthosting.co.za>
In-reply-to
Content
"""
What do you think about the richer api I proposed here?
http://bugs.python.org/issue18835#msg232221
"""

msg232221:
"""
For numpy's purposes, I think the best approach would be to add a tracemalloc "escape valve", with an interface like:

PyMem_RecordAlloc(const char* domain, void* tag, size_t quantity, 
PyMem_RecordRealloc(const char* domain, void* old_tag, void* new_tag, size_t new_quantity)
PyMem_RecordFree(const char* domain, void* tag)
"""

I don't plan to store new information in tracemalloc. tracemalloc design is "simple": it stores a trace for each memory block. A memory block is identified by its address (void* pointer) and a trace is a tuple (size, traceback).

Extending a trace would increase the memory footprint overhead of tracemalloc.

Note: I don't understand what are domain, tag (address of the memory block?) or quantity (size of the memory block?).

Storing the C filename and C line number was proposed but rejected in the design of the PEP 445:
https://www.python.org/dev/peps/pep-0445/#pass-the-c-filename-and-line-number

I'm open to extending tracemalloc, but it requires to discuss the API and how changes will impact the code (tracemalloc, but also users of the tracemalloc API).
History
Date User Action Args
2016-03-11 17:52:52vstinnersetrecipients: + vstinner, pitrou, njs
2016-03-11 17:52:51vstinnersetmessageid: <1457718771.98.0.98972359451.issue26530@psf.upfronthosting.co.za>
2016-03-11 17:52:51vstinnerlinkissue26530 messages
2016-03-11 17:52:51vstinnercreate