[Python-Dev] PEP 454 (tracemalloc) disable ==> clear? (original) (raw)
Victor Stinner victor.stinner at gmail.com
Wed Oct 30 11:02:59 CET 2013
- Previous message: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?
- Next message: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
2013/10/30 Jim J. Jewett <jimjjewett at gmail.com>:
Well, unless I missed it... I don't see how to get anything beyond the return value of gettraces, which is a (time-ordered?) list of allocation size with then-current call stack. It doesn't mention any attribute for indicating that some entries are de-allocations, let alone the actual address of each allocation.
get_traces() does return the traces of the currently allocated memory blocks. It's not a log of alloc/dealloc calls. The list is not sorted. If you want a sorted list, use take_snapshot.statistics('lineno') for example.
In that case, I would expect disabling (and filtering) to stop capturing new allocation events for me, but I would still expect tracemalloc to do proper internal maintenance.
tracemalloc has an important overhead in term of performances and memory. The purpose of disable() is to... disable the module, to remove complelty the overhead.
In practice, enable() installs on memory allocators, disable() uninstalls these hooks.
I don't understand why you are so concerned by disable(). Why would you like to keep traces and disable the module? I never called disable() in my own tests, the module is automatically disabled at exit.
Victor
- Previous message: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?
- Next message: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]