Message261586
| 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:52 | vstinner | set | recipients:
+ vstinner, pitrou, njs |
| 2016年03月11日 17:52:51 | vstinner | set | messageid: <1457718771.98.0.98972359451.issue26530@psf.upfronthosting.co.za> |
| 2016年03月11日 17:52:51 | vstinner | link | issue26530 messages |
| 2016年03月11日 17:52:51 | vstinner | create |
|