ISystem without burst is slower than SystemBase without burst

[jagged dew]

From my last testing it's ISystem without burst is slower than SystemBase without burst. Any plan to improve it to at least on par with SystemBase without burst performance and even better make it faster than SystemBase without burst?

[strange ibex]

Could you show said difference?
The main difference between the two is that ISystem does have to go through a function pointer, and SystemBase doesn't.. That said, I would love to see a profiler result 😄

[jagged dew]

Sorry for late reply. Here's the profiler result

[terse granite]

Can you share the code for the system? I have seen isolated instances where a Burst-compiled ISystem is slower than the same system without [BurstCompile], but a) it's been difficult for other developers to reproduce, and b) the systems in question are usually doing so little work that it's pretty much a wash either way.

[jagged dew]

Ok. I think I can just PM u the project

@terse granite PMed

[terse granite]

Oh sorry, I misread your message; you're saying that ISystem without Burst is slower than SystemBase without Burst. My early-morning brain read that as "ISystem is slower with Burst than ISystem without Burst".

Recalibrating for the actual problem: I'm not too familiar with the internals of ISystem, but it was definitely designed with Burst-compatibility first & foremost. It is certainly conceivable that its fixed overhead per update could be higher than SystemBase's if Burst is disabled. But that should only affect the overhead, which according to your profiler capture is on the order of 10s of microseconds; I'd expect the actual OnUpdate() contents to compile & run more or less identically in both cases.

The straightforward workaround is to just keep using SystemBase in those cases, if your profiling show that's it's significantly faster.

[jagged dew]

I see but will ISystem eventually replace SystemBase in future? If I rememeber correctly previously the plan is to have struct type ISystem and class type ISystem

[terse granite]

We have no current plans to remove SystemBase from the API.

I can reproduce your results locally FWIW. though with a smaller difference. (results in microseconds):

From a few quick inquiries, my colleagues don't sound too surprised that this would be the case; there's more bookkeeping necessary in ISystem to work around some of the managed conveniences we have to avoid to keep things Burst-compatible. But the speedup from Burst more than makes up the difference in the common case.

Improving ISystem performance without Burst isn't likely to be a particularly high-priority target. ISystems looping on the main thread over MonoBehaviours isn't really how the package is intended to be used, outside of a few niche cases where it's necessary to interact with GameObjects from ECS-land. If the majority of systems in an application are doing this sort of work, that sounds like a poor fit for Entities in the first place.

(see also this thread re: guidance on ECS/GameObject interactions, and minimizing the number of systems in which this is needed: https://discord.com/channels/489222168727519232/1050102065428447382)

[jagged dew]

Ya. I ady tried a couple of ways to sync ECS to game object. Anyway I will stick to SystemBase if I need to access managed component. Btw is that ok to use idiomatic foreach at SystemBase for this managed component access?

[terse granite]

Yes, as far as I know