I have been trying to improve the time performance of my project recently with the Unity profiler.
One significant part of the CPU usage (40-50%) was under Obi fixed updater, "semaphore. wait for signal". As shown in the attached image.
I did some googling and it seems like that updater was waiting for the frame to be rendered? Just want to confirm this is correct and I should work on simplifying the rendering process.
21-11-2023, 08:27 AM (This post was last modified: 21-11-2023, 08:32 AM by josemendez.)
(20-11-2023, 07:57 PM)Henning Wrote: Hi Obi team!
I have been trying to improve the time performance of my project recently with the Unity profiler.
One significant part of the CPU usage (40-50%) was under Obi fixed updater, "semaphore. wait for signal". As shown in the attached image.
Hi,
There's no image attached to your post. Either paste a link to it, or attach the file to the post (make sure you press "AddAttachment" after dragging the file!).
(20-11-2023, 07:57 PM)Henning Wrote: I did some googling and it seems like that updater was waiting for the frame to be rendered? Just want to confirm this is correct and I should work on simplifying the rendering process.
Not at all, "wait for signal" just means the main thread is waiting for something. Could be rendering, could be physics, AI, input, literally anything, depends on the context. If it's happening in FixedUpdate(), a safe guess would be it's waiting for other threads that are performing physics simulation.
Check other threads in the profiler, see if they're doing any work while the main thread waits. If they are, it means the main thread is waiting for them to finish so your focus should be on optimizing whatever those other threads are doing.
There's no image attached to your post. Either paste a link to it, or attach the file to the post (make sure you press "AddAttachment" after dragging the file!).
Not at all, "wait for signal" just means the main thread is waiting for something. Could be rendering, could be physics, AI, input, literally anything, depends on the context. If it's happening in FixedUpdate(), a safe guess would be it's waiting for other threads that are performing physics simulation.
Check other threads in the profiler, see if they're doing any work while the main thread waits. If they are, it means the main thread is waiting for them to finish so your focus should be on optimizing whatever those other threads are doing.
kine regards,
Hi Jose,
Sorry for the image! I attached it this time. Many thanks again!
21-11-2023, 12:26 PM (This post was last modified: 21-11-2023, 12:28 PM by josemendez.)
(21-11-2023, 11:06 AM)Henning Wrote: Hi Jose,
Sorry for the image! I attached it this time. Many thanks again!
Regards,
Hi,
Typically it's easier to make sense of how threads relate to each other in timeline mode, that way it you can clearly see how threads wait for each other and what each one of them is working on. Hierarchy mode is only useful for sorting function calls by cost.
In your case, BurstColliderWorld.GenerateContacts is taking 24 ms/frame, which is a lot. Either it is not getting properly compiled by Burst, or you have an enormous amount of very complex colliders in your scene.
Would it be possible for you to export your profiling session and share it with me? (either posting it here if it's small enough, or by sending it to support(at)virtualmethodstudio.com). That way I can take a better look at it.
23-11-2023, 09:55 AM (This post was last modified: 24-11-2023, 09:37 AM by slimedev.)
Updating Obi from 6.5.2 to 6.5.4 fixed a similar issue for me.
I also downgraded Mathematics (I think...) from Experimental to Release version - Not sure if that did anything, but I had stumbled on a thread here on Jobs performance and Package updates so figured I'd try that too.
