[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1009970: RFP: memray -- Python memory profiler



Package: wnpp
Severity: wishlist

* Package name    : memray
  Version         : 1.0.3
  Upstream Author : https://github.com/pablogsal and bloomberg
* URL             : https://bloomberg.github.io/memray/
* License         : Apache 2
  Programming Lang: Python
  Description     : Python memory profiler

Memray is a memory profiler for Python. It can track memory
allocations in Python code, in native extension modules, and in the
Python interpreter itself. It can generate several different types of
reports to help you analyze the captured memory usage data. While
commonly used as a CLI tool, it can also be used as a library to
perform more fine-grained profiling tasks.

Notable features:

 * Traces every function call so it can accurately represent the call
   stack, unlike sampling profilers.

 * Also handles native calls in C/C++ libraries so the entire call
   stack is present in the results.

 * Blazing fast! Profiling causes minimal slowdown in the
   application. Tracking native code is somewhat slower, but this can
   be enabled or disabled on demand.

 * It can generate various reports about the collected memory usage
   data, like flame graphs.
    
 * Works with Python threads.

 * Works with native-threads (e.g. C++ threads in C extensions).

Memray can help with the following problems:

 * Analyze allocations in applications to help discover the cause of
   high memory usage.

 * Find memory leaks.

 * Find hotspots in code which cause a lot of allocations.

----

There are already other Python profilers in Debian, but this one is
pretty extensive and surprisingly powerful. Flamegraphs, live
debugging, including of native code, doesn't have an equivalent in
Debian right now, as far as I can tell.

Requires libunwind according to the README, which shouldn't be a
problem for us. It does seem to also have JS dependencies which could
be more of a problem, but it's very minimal compared to JS-only
projects.

This should probably be maintained by the Python packaging team, but I
don't have the cycles to spearhead that effort myself.


Reply to: