I notice sample input system at GhostInputSystemGroup is really slow that slowdown by
GhostUpdateSystem massively at my actual project. The small repro doesn’t seems too slow at editor but when u build test Android player runtime build, you will see it slowdown significantly and it’s even over 2x slow at my actual project. If I remember correctly before 1.0 release, it’s capture input first then only update ghost. Is there any reason why this update order has been reverse? I think change the update order back to be like before 1.0 should fix GhostInputSystemGroup issue. If look at another perspective, it is caused by mobile platform related input is not burst compatible and make it not able to jobify the code that causes this slowdown.
And also other than sample input system, there are a couple of places that causes the slowdown that official needs to improve them. All these slowdowns add up make Android player runtime build too slow and performance really unstable that keep spiking up and down at actual project. Moreover I spotted there’s job still not burst properly yet which surprise me. Not sure if there’s more not yet burst job but from what I see I believe that not yet burst job is from Transport package.
for the burst job, please open a case in relation to them or post here what are the system/job you talking oabout.
For the input, it is not the system fault or the position itself that is causing the problem but the job scheduling and/or dependencies.
The GhostUpdateSystem is actually running before the GhostInputsystemGroup for two reason:
enable/disable the GhostOwnerIsLocal component based on the received data from the server.
use the last data received from the server for owned ghost (in case necessary)
update of the events (when using remote player prediction)
IIRC correctly we changed that because mostly to have the GhostOwnerIsLocal up to date. But we should investigate about these stalls. This is obviously waiting for the GhostUpdateSystem jobs to complete, because you are accessing some component that is being accessed by the jobs, from the main thread.
Is this system in your project (the one you shared?)
Yes. See SampleCubeInput system. Btw there are also a couple of systems that have stall issues caused by job scheduling and/or dependencies too like GhostCollectionSystem,PredictedSimulationSystemGroup, GhostPredictionDisableSimulateSystem, Cube.Generated.CubeInput_ApplyCurrentInputBufferElementToInputDataSystem and etc. Dun forget to check them too.
Ya. You can check both the IN-33610 and repro project I shared to u that both have similar issue but for repro project u can see much obvious stall at a couple of places. Anyway will it improved at next release?
@CMarastoni Will the most of stalls if not all the stalls be fixed at next 1.0 release? At least I would like official to fix the stall at GhostInputSystemGroup first.
To clarify: It is not a stall but It is just a required dependency for use the IsOwnerLocal. That because, we need to run a job that requires the GhostUpdateSystem run first.
This is why the order has been reversed. By reverting the order:
You have one frame delay from the ghost spawn to when you can actually control (that it is completely fine)
You will continue to “control” a ghost even if you the IsOnwerLocal if false, for one extra frame, but the command will be discarded on the server.
I think the flow can be optimised and most of the stall removed. This will not happen for the first 1.0 release. But we will release an update shortly after where we can improve this.
Actually from what I know there’s bug at Entities that the stalling is caused by codegen issue that even u use RefRO but at the end it’s still treated as RefRW that ends up u need to wait for the write data to complete first hence the stalling. Will need someone to look at this issue.
