[1.0.0-pre.65] Request system rest for enableable component query

[carmine juniper]

Currently when u have enableable component at RequireForUpdate, no matter the component is disabled or enabled, it will just match the query and then run OnUpdate() which increase the time spent on system even u don't want the system to run. The time spent on system OnUpdate() still ok if u didn't work on netcode project but at netcode project when using prediction system, it's extremely costly for each system specially at mobile platform. The highest time spent at android I observed can reach until a around 0.35ms+ for just only 1 system. The only work that the system does is just schedule IJobEntity or go through idomatic foreach and nothing more. I would like official to make all the systems rest for the disabled enableable component that not match the query. The only current solution at pre.65 I can do is reduce the system as much as possible and make most of the system rest as much as possible too.

[tall briar]

this will result in opposite: checking query for emptiness will be extremely slower for every system

resulting in much worse performance overall

are you sure scheduling job is the biggest overhead?

potentially you are causing sync point

which results in main thread being locked until blocking jobs are finished

[carmine juniper]

Not really. When the system is rest only spends 0.01 ms. No matter it's schedule job or going through idomatic foreach will spend quite a lot of time.

[tall briar]

then you probably have sync point

[carmine juniper]

No sync point

[tall briar]

mind showing profiler for that system?

it's rather interesting what exactly is taking 0.35ms

[bold narwhal]

Any check on enable component on main thread is a sync point on that dependency chain

Because you're allowed to change enableable in a job

So it has to sync to check it on main thread

You can implement this behaviours yourself if you want

Just use IsEmpty on a query instead of IsEmptyIgnoreFilter to early or and not schedule

[carmine juniper]

Tried. The time spent still really high that actually just like before apply this query check. I guess need official to figure out better solution to really solve this problem

[tall briar]

scheduling job can't possibly take 0.35ms

so whatever it is

it can't be it

[carmine juniper]

[1.0.0-pre.65] Request system rest for enableable component query

[carmine juniper]

@ripe edge So this the reason why I need system to rest but looks like make it not match the query for disabled enableable component will have sync point, so I propose another solution.
The solution is to make it only schedule job once / run idiomatic foreach query once during system update to minimize the time spent significantly. I checked profiler one system around 0.035ms+ when run only once but since prediction system will run multiple times, it will become to like around 0.35ms+. After this optimization, I believe it can lower down 0.035ms+ or even lower per system which is really fast. Really need this optimization implements at post 1.0 release.

[bold narwhal]

I'm confused what you're asking

Why is it running multiple times in a single update?

[carmine juniper]

Coz the system is at predicted system group

[bold narwhal]

Then it has to run multiple times

That's how prediction works

If it's not meant to be predicted move it outside the group?

[carmine juniper]

Ya. What I propose is to make job scheduling / idiomatic foreach query to make do it once but the system logic inside u still run it multiple times at predicted system group.

For example: Let say the system run 10 times during prediction, each job scheduling / idiomatic foreach spends 0.35ms (0.035ms x 10). After the optimization, job scheduling / idiomatic foreach will run only once and now only spends 0.035ms which is 10x improvement. So if have 10 system which is 100x improvement.

[ripe edge]

uh, but the job scheduling and ife can have different results on different predicted ticks

you only find out they were the same by running them

[carmine juniper]

🤔 Technically since prediction is run multiple times in one frame and during that update it most probably won't change query results until next new frame update

[ripe edge]

there’s absolutely no guarantee that the query results won’t change, and as soon as they do you have incorrect results

prediction is expensive, man; I imagine it’s uncommon on slow phones partly for that reason

[carmine juniper]

😂 Actually even at desktop pc it's also damn expensive

[ripe edge]

yep!