Can memray see allocations made by compiled code?

[tomwhite]

This might technically depend on whether you only care about Python-level copies. I think that for any of the range requests zarr makes, those only use a single allocation on the Rust side. But I'm not 100% sure that there's not an extra copy on the Rust side when you call bytes_async(). That calls the underlying bytes method of the object_store GetResult. And that could have copies under the hood.

Can memray see allocations made by compiled code?

Originally posted by @kylebarron in 2767ed5

[tomwhite]

Thanks for the comments and question @kylebarron. We should care about all copies made in the stack, but I haven't had much luck getting memray to give much more than the overall size of allocations in Rust. Even when I enable native_traces (https://bloomberg.github.io/memray/api.html#memray.Tracker) it shows that there are allocations, but can't find line information. I'm not sure if this is a problem on Mac, or more generally on Linux too. (I will update the flamegraphs in this repo with native_traces enabled since it helps visibility with C code at least.)

There's possibly another problem with the asynchronous nature of the underlying code since it means the peak memory allocated is not always consistent (maybe?), and certainly is harder to follow in the flamegraph stack traces.

[tomwhite]

I updated the script to run with native tracing (7a9f5c9). Here's an example with obstore where it just says <unknown> at <unknown>:0 for what are presumably the calls into Rust: https://tom-e-white.com/memray-array/flamegraphs/write-local-zarr-v3-obstore-uncompressed.bin.html. This is known not to work well on Mac, but I haven't tried it on Linux (I'd probably have to set up CI to do that).

[kylebarron]

At some low level, any tool making network requests will have to materialize the stream, and that could count as multiple allocations depending on how you think about it.