Supported Python interpreters#
Only CPython is supported.
Supported Python versions#
Every Python version that hasn’t reached end of life is supported.
Currently that’s Python 3.7 through 3.11.
Supported operating systems#
You will have the best Memray experience on Linux.
We also support macOS 11 or newer. We cannot support older macOS versions, as they don’t provide a C++17 compatible runtime. Although all features work on macOS, the way that macOS applications and Python libraries are typically distributed often results in subpar native stacks on Mac. See the native mode documentation for details on these shortcomings.
We are unlikely to ever support Windows. While the basic technique that Memray uses to detect memory allocations is possible on Windows, much of the library would need to be rewritten to support non-POSIX platforms, and none of the current maintainers have the expertise to do so. We do test in WSL, however.
Supported CPU architectures#
For Linux, we test on
aarch64. Pre-built wheels
are only available on PyPI for
x86-64, though. That is
unlikely to change until cibuildwheel provides non-emulated aarch64 support.
For macOS, we test on
arm64 - so, both Intel and Apple
Silicon Macs. Pre-built wheels are available for both architectures, though
only for Python 3.8 and newer.
Supported runtime environments#
We require a C++17 runtime. As noted above, macOS 11 or higher is required for a C++17 runtime on Mac.
On Linux we support glibc and musl libc. Other libc’s have not been tested, and
issues are likely. For Python 3.10 and earlier we support platforms compatible
manylinux2010 specification, and for Python 3.11 onward we require
Known issues and limitations#
Native stack traces on macOS are often difficult to read, and may be missing function calls. See the native mode documentation.
We support tracking across forks, but can’t track across an
exec, so if the tracked child process calls an os.exec function, even to start a new Python interpreter, we will not be able to report the allocations performed in the new process. Notably, the default multiprocessing start method on macOS is “spawn”, which leverages
Cython functions will not be included in the Python stacks we report, even if the Cython module is built with profiling support. You’ll need to use Native tracking to see what’s happening inside Cython modules.
We have experimental support for the
greenletlibrary, which may lead to incorrect stacks being reported if the Memray API is used to start tracking in one thread while another thread is already making use of the Greenlet library.