2013/10/19 Charles-François Natali <cf.nat...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com