Resizing a NativeHashMap, based on an EntityQuery

Unity Engine
, ,
1

I’ve designed myself into a situation where I really don’t want to be: needing a NativeMultiHashMap, with a capacity that’s dependent on the number of entities involved in an EntityQuery.

Normally, I try to avoid this pattern, because it would require clearing and resizing the hash map each frame. And on top of that, EntityQuery.CalculateEntityCount() is a very, very costly method to call.

But before giving up on this approach, I wanted to try doing this work in a Bursted job. Maybe that could bring down the cost enough for it to be valid? It’s at least worth testing to be sure.

My main goal was to be able to call EntityQuery.CalculateEntityCount() from inside an IJob, since that function is truly expensive. However, predictably, I ran into issues. This point of this post is to make sure I’m not missing something that would make this work. Please advise if I’m being dumb. And thank you!

My job:

[BurstCompile]
private struct PrepareTestMapJob : IJob
{
    [NativeDisableUnsafePtrRestriction]
    public EntityQuery query;
    public NativeMultiHashMap<int, int> map;

    public void Execute()
    {
        int entityCount = query.CalculateEntityCount();

        map.Clear();

        if(map.Capacity < entityCount)
        {
            map.Capacity = entityCount;
        }
    }
}

The job Burst compiles fine, based on the Burst inspector. When I run it in Playmode, I get this error:

Am I missing something obvious here, or is it just unavoidable that EntityQuery.CalculateEntityCount() would need to be called from the main thread, during my system update? If so, that puts the final nail is this line of thinking.

2

Note that CalculateEntityCount() already uses Burst even when invoked on the main thread. It is one of many BurstMonoInteropMethods (actually it is a wrapper around one) which can be invoked in Mono or Burst contexts and always runs in Burst.

However, if the real issue is main thread time somehow being more expensive than scheduling a job, then you can use an ArchetypeChunkIterator and IJobEntityBatch.RunWithoutJobsInternal().

And no I have no idea why it is suffixed with “Internal” despite being public and despite IJobChunk having a similar method without the suffix.

Or maybe this has the same problem and you just need to add NativeDisableUnsafePtrRestriction to your EntityQuery in your job.