Memory Profiler: NativeArray, NativeList etc

The memory profiler doesn't seem to show any memory created using NativeArray/NativeList - which are drastically lacking in useful ways to track memory usage/leaks. Is this supported and I am missing something or is there a specific view or option to use? I have hundreds of MB of NativeArray data that is completely absent from the memory profiler

 

I spent the day trying to debug some issues with NativeLists that were getting wildly out of hand, and consuming crazy amounts of memory. We didn't lose references to them, so they were not "leaked" but the capacity had grown to very large levels and really inflated our memory usage. I hoped that the memory profiler would give me some clues in to what on earth was going on, as at the beginning it was not even clear where the memory was coming from. When I began, I did not even know where the memory was coming from

When I first jumped into the memory profiler, it was as if they didn't exist - there didn't seem to be any clear view to see them at all, so at first it misguided me into thinking that no memory was being taken up by NativeList/NativeArray collections

 

I don't like necroing threads but I came into this as well over a year later.

I noticed that NativeArrays are hard to track down allocations. I have a keybind command that initializes a couple hundred of them with Allocator.Persistent in a single frame, and the profiler doesn't show any of them being allocated for in the frame. The profiler window's memory view just shows 1MB being allocated in the frame in both editor and windows standalone, but there's definitely more than that being allocated and used with NativeArrays. Unity memory will jump 0.50GB total when I do this in a single frame.

But if I use the dedicated MemoryProfiler for some reason, it doesn't show up in the tree map. I have to go into Table -> Alloc -> ByNativeObject and expand by N/A. Of which, it doesn't really give me useful info.

I really wish we could give these things markers or have some way of tracing them. I know they definitely store trace calls somewhere when you turn on Full Stack Leak Detection in the editor. I'm using 2019.4.3f1 by the way.

 

Glad to know it hasn't been forgotten! Thanks for the speedy reply.

Just like a ProfilerMarker I'd expect to be able to pass in a string or maybe some kind of integer id the user can just map out themselves (since I know jobs can be picky even with static strings in profilermarkers). And when we see it in the profiler appear like a profilermarker with that identifier, we can simply see what size it was initially allocated for. NativeLists is probably a bit trickier to track, but at least Arrays are fixed. If it's a release build, compile it out conditionally.

I was thinking of making my own static API for allocating and tracking them, just like a profilermarker would, for the time being and either dump the data it's tracked on command or maybe even just leveraging a profilermarker name somehow (even if it means paying for the string manipulation for the marker to show the numbers).

To give you an idea of a problem I'm trying to track down: I'm noticing that when I fire my command that's allocating a bunch of fragmented/different NativeArrays (persistently),that Unity is reserving upwards of 0.50GB memory, but I'm expecting only 100MB at most. The Profiler window, if I take a sample directly in that, before and after shows NativeArray size exploding from modest 80MB to upwards of 0.50GB. The same in the Memory Profiler window if I drill down into the tables.
I'd expect 180MB but instead I'm seeing 4x that and I have no idea why or where. Obvious assumption is that my math is horribly wrong in one of these allocations. Identifying where though is the troublesome bit. I can see where profiling is taking the longest, but the math checks out (its just a lot of small allocations that only add up to a couple of MB). The fastest and "truest" way to fix what I'm investigating (and to speed it up performance wise) is just making an arena/contiguous chunk allocator that's pre-allocated from the beginning of the scene, but it would be nice to know where I went wrong originally lol