NativeArray allocation performance

[manic loom]

You could use persistent allocated NativeArrays, either as a pool or just one big array that you slice as necessary.

Are most of the NativeArrays you're allocating 1-element long ones just to return a value?

[main tapir]

I am writing my quad tree used in path finding (not storing point)
But in your case, i suggest you need a fixed size buffer on each node to store the point so that you can allocate a large array as a pool to get node
But notice that each node has a capacity so if you have a cluster of point that close to other point the depth will grow deep (you have to continuously subdivide the region

if the size of AABB of each node of your quadtree has a lower bound, then you will need a dynamic array for storing the points
otherwise just keep subdivide until all points are stored

[random shoal]

I pass the object along with its found neighbors each into their own job to check and resolve movement and collisions for that object (in -> a collider info NativeArray, out -> a 1-index-long Vector2 position NativeArray)
Can you not do this in a ParallelFor job with all these things in a single NativeArray and all the results in a single NativeArray?

[dreamy apex]

That's a good question- I'll profile it now and see if I can figure out why my allocations seem freakishly high

[dreamy apex]

I'm afraid I don't fully understand-- do you mean passing in every collider info of every object in a single nativearray?

(Then just computing collisions off of that)

(If I'm assuming correctly) I'm apprehensive to follow that since I don't want compute every collider against one-another over concerns of performance exponentially growing (hence my clinginess to aggressively leaning into the quadtree)

[dreamy apex]

I implemented a pretty optimized tree, though I do need to eventually switch to proper delta tracking instead of dirty-flag caching sometime soon- then again it's far from the largest performance drain so that'll be an optimization way down the line (if at all)

[random shoal]

Yes this is typically how parallFor jobs work and get the benefit of contiguous memory allocation

[random shoal]

You wouldn't be doing this

[dreamy apex]

Would I instead just pass in like the indicies each one is looking for? I.e. Object 1 wants to check against the object at index 3, 6, and 24

[random shoal]

Where do you get those indices from? You could store those indices in a NativeMultiHashMap

Then you can look up which objects the current collider cares about in the job @dreamy apex