Cache NetworkTime.PhysicsFactor

[quickstraw]

Each time NetworkTime.PhysicsFactor is called, and a cross-language call happens, which takes up a small but noticeable amount of time. Using dotTrace, these calls take up 1.93% of time for my own game. Caching this value in my own project has eliminated this to <0.01% of time.

I'm not sure if this number is ever recalculated during runtime, so maybe this would not fix this issue.

[quickstraw]

After looking at it more, my project always has the factor of 1 because it is synced to physics, so it matters a lot less for me.

[DustieDog]

Thanks for the feedback! physics_factor is calculated each frame when not syncing to physics (and as you discovered is constant when you sync to physics), so caching would be out. Do you have benchmarks of how long the calls took and now many nodes you were running that called it?

[quickstraw]

Using dotTrace sampling, it took 1,716 ms out of 78,944 ms (length of the profiling snapshot). Since I was syncing to physics, I replaced it with 1. After that, the time to get that constant physics_factor was just 11 ms out of 168.081 ms.

There were about 100-200 nodes (I was spawning and despawning nodes during the test) that were calling physics_factor each tick twice per tick. I could easily simplify that to only call physics_factor once per tick per node (store when the active node first calls it), which should take half the time.

Half the time would be about 0.9% of the total profiling time. While not a ton of time overall, it is a pretty big cost considering it is basically just a getter.

In the end, I've decided to make the non-player nodes sync over the normal Godot Multiplayer API. Since I'm just syncing up to 4 players using Netfox, calling physics_factor is a negligible cost for me.