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

[Victor Stinner]

2013/10/19 Charles-François Natali <cf.natali at gmail.com>:
>> get_object_trace(obj) is a shortcut for
>> get_trace(get_object_address(obj)). I agree that the wrong size
>> information can be surprising.
>>
>> I can delete get_object_trace(), or rename the function to
>> get_object_traceback() and modify it to only return the traceback.
>>
>> I prefer to keep the function (modified for get_object_traceback).
>> 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 get_object_trace(): even if
> it uses get_trace() 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 get_object_trace() public, and make
> get_object_address() and get_trace() 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 get_stats() and
>> high-level like Snapshot) for similar use cases? What do you suggest?
>
> I didn't understand your above explanation: could get_stats() 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