Something else I was wondering is there

[fair steppe]

There should not be any difference. The main bit is the overhead added when dealing with enableable components that is auto-generated into your IJobChunk when using IJobEntity (since IJobEntity generates IJobChunks under the hood).

[bitter shore]

the ChunkEntityEnumerator?

[bitter shore]

Also, what about if I have multiple jobs in the same system that could share a ComponentLookup, ComponentTypeHandle, etc, is there any significant overhead from not updating a shared resource once, or does the code generation handle this?

[fair steppe]

the ChunkEntityEnumerator?
No looks like the code generation does use that but performs does something very similar. You need to figure out which components to actually look at via enabled bits so there are some additional loops that can be baked in to the chunk iteration that are skipped if you use IJobChunk directly, but then it's on you to do that work if you care about if something is enabled (in which case IJobEntity is likely better to use). But if you want to operate on chunks at a time for your own purposes you certainly get more "direct" access with IJobChunk and looks like useEnabledMask is actually always forced off for your Execute() which is a bit interesting as I suppose you could actually ignore that and filter components yourself with say a ChunkEntityEnumerator

[bitter shore]

And is this an issue? Is the overhead on calling Update significant or does it not really matter? (ideally the code generation would share them between jobs but I don't know if this currently happens)

[fair steppe]

is there any significant overhead from not updating a shared resource once, or does the code generation handle this?
With safety checks off, the cost is minimal/basically free (single store in most cases). It's still small with safety checks but not free since it needs to touch a few different arrays of safety data.

The codegen should be emitting .Updates for you. In general you should not need to worry about it as we expect this to be called a bunch by codegen at the moment.

[radiant nymph]

There are a bunch of optimisations you can do on a per chunk level though with ijobchunk
An obvious example is per chunk allocations instead of per entity

[fair steppe]

Most certainly. When your focus is specific to chunks you can remove all entity overhead by using them directly. But if you're working on entities there should be no difference between them

[radiant nymph]

I actually think you're code gen would probably produce better results sometimes

Since it ensures attributes like noalias etc

And you can update it in the future with further optimisations from new apis

While a user is going to have to go and manually update all their ijobchunk jobs

[fair steppe]

I agree, you can reach for all the same tools manually using IJobChunk but IJobEntity should handle things for you and indeed, in a future-proof way.

IJobChunk can quickly get into "I know how chunk data is laid out and stored in archetypes" territory all of which are implementation details