[Python-Dev] PEP 454 (tracemalloc): new minimalist version (original) (raw)

Victor Stinner victor.stinner at gmail.com
Sun Oct 20 17:03:19 CEST 2013

2013/10/19 Charles-François Natali <cf.natali at gmail.com>:

getobjecttrace(obj) is a shortcut for gettrace(getobjectaddress(obj)). I agree that the wrong size information can be surprising.

I can delete getobjecttrace(), or rename the function to getobjecttraceback() and modify it to only return the traceback. I prefer to keep the function (modified for getobjecttraceback). tracemalloc can be combined with other tools like Melia, Heapy or objgraph to combine information. When you find an interesting object with these tools, you may be interested to know where it was allocated. If you mean modify it to return only the trace, then that's fine. As for the name, traceback does indeed sound less confusing than trace, but we should just make sure that the names are consistent across the API (i.e. always use "trace" or "always use "traceback", not both).

I'm not sure that you understood my proposition. Extract of the doc:

Example of trace: (32, (('x.py', 7), ('x.py', 11))). The memory block has a size of 32 bytes and was allocated at x.py:7, line called from line x.py:11.

A trace is (size, traceback). Currently, get_trace(address), get_object_trace(object), get_traces() return traces.

You look to be confused by get_object_trace() returning a trace because the size may be smaller than the total size.

I proposed to rename get_object_trace() to get_object_traceback() and modify it to only return the traceback: (('x.py', 7), ('x.py', 11)).

But get_object_trace/traceback() can also be removed, because it's trivial to reimplement it using get_object_address() and get_trace(). It's maybe less suprising to get a wrong size using get_trace(get_object_address(obj)).

Well, I can certainly find a use-case for getobjecttrace(): even if it uses gettrace() internally, I'm not convinced that the later is useful.

If we cannot come up with a use case for working with raw addresses, I'm tempted to just keep getobjecttrace() public, and make getobjectaddress() and gettrace() private. In short, don't make any address-manipulating function public.

I would like to keep functions using addresses. Usecase: call get_traces() to get all traces, and then (maybe after the process exited) use it to get the trace of different objects using get_object_address().

[Filter.match*] IIUC, you only use those match methods for tests and internally for code factorization: IMO, that's a hint they shouldn't be made public.

Ok, I made the methods private.

I already used other tools like Melia and Heapy, and it's convinient to get access to raw data to compute manually my own view. I don't want to force users to use the high-level API (Snapshot).

Is it a problem to have two API (low-level like getstats() and high-level like Snapshot) for similar use cases? What do you suggest? I didn't understand your above explanation: could getstats() be implemented atop a snapshot, or not?

get_stats() cannot be implemented on top of Snapshot.

Humm... I didn't see any metric example at http://www.haypocalc.com/tmp/tracemalloc/library/tracemalloc.html Is it me?

http://www.haypocalc.com/tmp/tracemalloc/library/tracemalloc.html#metric "Example of metrics: Resident Set Size (RSS) memory of a process, memory in bytes used by Python, number of Python objects, etc."

Did you expect something else for examples?

Victor

More information about the Python-Dev mailing list