Difference between IJobEntity, IJobChunk?

[hellengoodd]

in EntityComponentSystemSamples\ECSSamples\BoidSystem.cs

I found that code partial struct InitialPerBoidJob : IJobEntity
automatically generates to the code partial struct InitialPerBoidJob : IJobChunk

and the file BoidSystem.cs automatically generates to the file BoidSystem__JobEntity_3566451.g.cs

so is IJobEntity equal to IJobChunk, if not, what difference between IJobEntity, IJobChunk?

[Luemus]

@hellengoodd

in EntityComponentSystemSamples\ECSSamples\BoidSystem.cs

I found that code partial struct InitialPerBoidJob : IJobEntity
automatically generates to the code partial struct InitialPerBoidJob : IJobChunk

and the file BoidSystem.cs automatically generates to the file BoidSystem__JobEntity_3566451.g.cs

so is IJobEntity equal to IJobChunk, if not, what difference between IJobEntity, IJobChunk?

Taken from the intro to entities documentation;

For jobs that access the entities matching a query, we have two special job interfaces:

• IJobChunk, whose Execute() method processes an individual chunk matching the query.
• IJobEntity, whose Execute() method processes the components of an individual entity matching the query.

IJobEntity is the convenience option, and IJobChunk is the fallback option for niche cases. In most cases, their performance is identical.

See examples of IJobChunk and IJobEntity.

To split the work of an IJobChunk or IJobEntity across multiple threads, schedule the job by calling ScheduleParallel() instead of Schedule(). When you use ScheduleParallel(), the chunks matching the query will be split into separate batches, and these batches will be farmed out to the worker threads. See related: EntityCommandBuffer.ParallelWriter

[hellengoodd]

@Luemus

Taken from the intro to entities documentation;

For jobs that access the entities matching a query, we have two special job interfaces:

• IJobChunk, whose Execute() method processes an individual chunk matching the query.
• IJobEntity, whose Execute() method processes the components of an individual entity matching the query.

IJobEntity is the convenience option, and IJobChunk is the fallback option for niche cases. In most cases, their performance is identical.

See examples of IJobChunk and IJobEntity.

To split the work of an IJobChunk or IJobEntity across multiple threads, schedule the job by calling ScheduleParallel() instead of Schedule(). When you use ScheduleParallel(), the chunks matching the query will be split into separate batches, and these batches will be farmed out to the worker threads. See related: EntityCommandBuffer.ParallelWriter

Thank you for your answer, this document has answered my question, but I have another question, that is: why the same partial structure can have different base classes…

[hellengoodd]

@""

They’re interfaces. You can always have multiple interfaces, for example in a struct implementing IComponentData and IEnableableComponent.
The mechanism of reusing the existing type simplifies things. The fields that users define in an IJobEntity job are ready to be used in a per-chunk job - plus the requisite ComponentTypeHandle / BufferTypeHandle etc. - so there’s then little need to synthesize a new struct altogether to hold the data for the chunk job, and the actual Execute method has a fixed signature that shouldn’t interfere with whatever the IJobEntity entry point is. Ultimately, IJobEntity is only really there as a convenience layer to write a per-entity action that always translates to an IJobChunk that uses that defined action, so it makes sense to just piggyback the user’s struct and make it be the “actual” job type.

Oh, that’s it, that’s the interface, I thought it was the class, thank you so much!