Tracemalloc C API scales poorly in multithreaded use

[ngoldbaum]

Numpy has some wrappers for data allocation that call into the tracemalloc C API. For example, here's the wrapper around malloc:

https://github.com/numpy/numpy/blob/f6440be7b8eec4a6481832f15f6730d984d78ef0/numpy/_core/src/multiarray/alloc.c#L255-L271

Recently a stackoverflow question led me to report a numpy issue about poor multithreaded scaling. I think the bulk of the scaling bottleneck is due to the global mutex in the tracemalloc implementation, as you can see in the flame graph and profile in the linked NumPy issue.

From the NumPy issue:

On my M3 Macbook Pro, I get the following stdout running the script:

Inner loops 10, multithreading  time: 6.68 sec, result sum: 717434683.1879175
Inner loops 10, multiprocessing time: 4.86 sec, result sum: 717434683.1879175

@Yhg1s told me on Discord that he has a patch that adds a fast path to tracemalloc based on an atomic flag and that seems to help a lot.

Linked PRs

• gh-143057: avoid lock in tracemalloc APIs when it is not enabled #143065
• gh-143057: Use atomics for _PyRuntime.tracemalloc.config.tracing #143066
• [3.14] gh-143057: avoid locking in tracemalloc C-APIs when it is not enabled (GH-143065) #143071