EntityCommandBufferSystem performance issue

[solid tiger]

When u are using EntityCommandBufferSystem like BeginSimulationEntityCommandBufferSystem, EndSimulationEntityCommandBufferSystem and etc. and then call CreateCommandBuffer() is quite high cost when u call it every frame at System. From what I understand when u are writing multithread code like IJobEntity, u are forced to call CreateCommandBuffer() outside of IJobEntity at System.OnUpdate() then only pass into IJobEntity. I would like official to make it possible to ECB.CreateCommandBuffer() inside of IJobEntity.

[bitter junco]

The creation cost of an ECB should be quite trivial, even if created every frame, so the behavior you describe sounds unusual. What Entities version are you using?

[solid tiger]

Latest 1.0.0-pre.15

[lapis estuary]

Do you have a profile result? 😄

[lapis estuary]

Which allocator are you using?

state.WorldUpdateAllocator is the one we recommend, as .Dispose is essentially a no-op in that case

[solid tiger]

🤔 Not like that? Seems like there's new state.WorldUpdateAllocator api I'm not aware of.
SystemAPI.GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>().CreateCommandBuffer(state.WorldUnmanaged)

[lapis estuary]

Hmmm oh yeah, from that api, it doesn't use it - I wonder which allocation it then uses gimme a sec

It uses the RewindableAllocator which should do the same

[bitter junco]

To clarify, are you seeing significant overhead in the CreateCommandBuffer call itself or just the Dispose? (The disposal should also be pretty trivial so this is probably still a legitimate issue)

[solid tiger]

I think is not CreateCommandBuffer call itself but at ecb system playback.

[bitter junco]

So in that profile, it looks like there's ~0.3ms non-Dispose time. How many commands are in the ECB's? If they're empty, 0.3ms does seem high, but otherwise could be totally expected.

[solid tiger]

Not really sure but at profiler there's 61 calls so I believe it's 61 commands keep calling every frame

I guess it will try to avoid calling CreateCommandBuffer() whenever possible but when using IJobEntity I think I dun have way to avoid it.

[bitter junco]

So you're calling CreateCommandBuffer 61 times? Or recording 61 commands into the ECB's?

[solid tiger]

61 systems so it's 61 different commands I believe

[lapis estuary]

All with their own CreateCommandBuffer i suppose?

[solid tiger]

Ya

[lapis estuary]

Well, there's a always a cost in having more systems vs individual ones, but even so, 0.17ms shouldn't be spend on disposing. I'll ask around, why that's the case, and how we can improve it.

In anycase, youre initial question of creating a commandbuffer inside IJE. likely wouldn't help your usecase in anycase