Should I be pooling NativeArrays set as persistent to avoid Fragmentation?

[woeful ingot]

I have a system that generates a bunch of native arrays, this native arrays are set to persistent because it can take long for the job requesting it to execute.

Sadly I've noticed what seems to be a lot of memory fragmentation. Should i be pooling these containers to avoid it?

[bright whale]

How did you measure the fragmentation?

As for pooling, probably? It's also possible to use a custom allocator that uses the persistent allocator as a backing allocator, which will allow you to group several arrays into bigger chunks of memory

If you know more about the sizes and lifetimes of your arrays, and the frequencies with which they're allocated, you can probably come up with a more optimal solution. If you need it.

[woeful ingot]

With the memory profiler, i've been seeing the Native reserved space increase but nothing else besides that so I assumed it's due to fragmentation.

[woeful ingot]

How does this custom allocator thing work?

[bright whale]

that's quite possible, do you have many different array sizes?

[bright whale]

detailed documentation is here for custom allocators
https://docs.unity3d.com/Packages/com.unity.collections@6.5/manual/allocator-custom-define.html

you can also use an existing allocator like the example here with the rewindable allocator
https://docs.unity3d.com/Packages/com.unity.collections@6.5/manual/allocator-rewindable.html?q=allocatorhelper

I think the simplest idea would be to use a rewindable allocator to allocate a big chunk of space upfront, then allocate your arrays from there. The trickiest part is then to figure out when you can free the memory again (i.e. track when all the jobs are done)

but it depends on your code

[woeful ingot]

Yup. I tried having one global big array but it still produced the same problem, but faster. According tonmy math, having them smaller should make the space allocated more reusable because the sizes repeat every so often