Hello. I have had help from many on this forum, and I have tried your suggestions. They all have their pros and cons, but I can't quite get the performance I need.. I have been working on many types of 2D spatial partitioning, but I always fall short just a little bit of my goal.. Context: Map in real units is 4-5km squared. I have 200k entities (rts units/soldiers) These units move in large formations together, but can also sometimes detach, so the map is either empty , sparse, or very dense. My Goal: To have a system (or set of systems) to be able to partition units on a 2D map based on their position. Then, use this information to determine circle collisions between units, and also to find the nearest enemy, and store a reference to that enemy for later use. The building of the partition and using the data can be on separate frame, if the grid/map/whatever is able to store a reference to the entities. The map is large, and the number of entities are large, and they are dynamic. Memory usage is ok up to around 6-700 mb. Unit colliders are circles only, and only vary in radius twice (men and horses). I do not need full physics sim, but simple collision separation and also mass for when units charge. Accuracy of collision can be sacrificed, as long as units do separate. For example, or the players tell all unit to go to one spot, and they are all bunching, as long as each unit is pushing away from at least 1 other, its ok. But if the units aren't bunched, they should always detect collisions (sparse). I have tried: NativeMultiHashMap Pros: Very soft on memory, 100% parallel, easy to use. Problems: After around 50-60k entities it really starts slowing down. 2D Grid (Array) The grids are definitely faster, but use a lot of memory. Smaller cell-sizes mean less checks, but much more memory. I have tried many different ways.. #1. Buckets in different ways. For example, each grid cell can hold 4 entities. So frame 1 partition units, frame 2, do an IJobChunk on all entities checking their cell, where index == unit position. This gives me the most accurate simulation, and allows me to use the partition data for other things. However this is slowed by all the random access to ComponentDataFromEntity accessed by the Entity in the grid cell. Or ,I stored indexes into the grid, and these indexes referenced "copyarrays" of componentdata similar to how the Unity boids example did it. These approaches saves me memory, as each cell is a maximum of 128 bytes (4 entities or ints), but is slowed down because of it. #2. Sacrificing a little accuracy for speed. Each grid cell could only hold one entity, and the grid cell size is halved (cell size is now the radius of an entity, so still pretty accurate). I tried this with storing entities, and it is a little faster but not much, because I am still using the entity for random access. I tried this by storing the actual positions, and radii of the units, instead of their index. This method achieved the speed I wanted, because I have no more random access to component data arrays. However, this meant I can not use the same partition for unit-enemy detection, and no entity is stored. The grid at this point is storing 3 values (x,y,radius), and takes up nearly .75 gb. So building another grid for entities for unit-enemy will use alot more memory. With this method, I also need to build and read the grid every frame, as I have no entity reference, however this method is still fastest! But it does not allow for the other functionality I need, At this point, I am trying to balance memory and performance, and I just cant quite seem to get it. #3. Representing by grid as a BitArray. This was the absolute fastest, and saved tons of memory. Each grid cell is one bit. The grid cell sizes were 0.25f, where a unit is 0.5f. I simply checked the 4 "big cells" (2x2, so 16 checks ) a unit was touching and if any bit were on, I approximated a collision saying the center of the colliding entity is the center of the cell. Since I check (cell entity is in, + 3 nearest cells), and each cell is really subdivided into 4 smaller cells (bits), I got a decently accurate result, and vectorized I am only doing 4 checks, not 16.. Again, like grid method #2, I cannot use this for finding nearest enemies. More details.. #4. Representing the grid as DynamicBuffers, but this was slower than a NativeArray. SCD Separating units based on SCD, but this didn't turn out well.. More Context With the grids, the write is single threaded but just as fast or even faster than the parallel NMHM write. This means in my other threads I can have another array keeping track of the number of entities per bucket. Of course, with my other grid method without buckets, I dont need this counter, which was another speedup. This also means for my bucketed approach, I can have 2 grids and write to one while clearing the old one in another thread, and alternating use. Again, not necessary for grid approach #2. For the NMHM I write one frame and read the next, and I have multiple maps, use a new one each time and every 8 frames clear them all. Overall, the writing to the partition isnt the bottleneck, its reading from it. I can't get rid of random access, while also preserving the two functionalities I need. So basically I feel stuck and if anyone has some insight into this, much appreciated. I can post code or benchmarks if you want.