DynamicBuffer vs NativeArray for a singleton

Unity Engine
,
1

I have a singleton array of data. Once upon a time the only way to have that was through ISharedComponentData. Now we have managed components that can hold a NativeArray, and we have DynamicBuffer.

Is there any reason to decide in favor of one or the other?

Neither can be used as a singleton directly so currently I’m using:
EntityManager.GetBuffer<ChunkBufferElement>(GetSingletonEntity<ChunkGrid>())

2

According to General purpose components | Entities | 0.3.0-preview.4 you should generally avoid using managed components due to their being less performant. Your current way of doing things looks good - GetSingletonEntity even throws an exception if 0 or more than 1 entities with the component are found

3

Right. Well, if they are talking about them not being jobified, then it’s obvious. But for singleton they would be fine.

I just remembered why I would really like to have managed singleton API (could do without it, but for convenience), it’s so that I can have hash maps in my components.

So in this case it works fine but before I had a dictionary instead. So managed singletons definitely make sense, and managed components as singletons won’t make any performance difference.

4

One benefit of using a DynamicBuffer:
The DynamicBuffer allows you to have write access in a Job automatically eg for updating the singleton data as this is solved automatically by the systems dependencies. Extracting the NativeArray and passing it to a job with write access will throw when some other job get’s it too.

5

I see. So this is why I couldn’t use a native array without a sync point. I thought the dependency system can handle all containers

Shouldn’t there be a way to “register” a container within a job, so that it is aware that it should wait for other jobs that are using this container to finish and then execute?

6

It catches the mistake deterministically instead of only failing once in a while on some machine with a specific number of cores, which is great.
The JobComponentSystem dependencies only involve access to ECS data.

7

This is a very useful thing to know, thanks. Still I’m very surprised that there is no system to include native containers in dependency handling.