liamc•10mo ago

Micro-optimizations to allow more dynamic objects

When profiling my game, normcore's Realtime.Update is consistently the most expensive part of my update loop. Even in a best case scenario, when idling in my game, when most objects are not moving, and we're not spawning any synced objects.
The most expensive method when idling is RealtimeModel.OnWillWrite. Within that, the most expensive OnWillWrite is RealtimeTransformModel, and within that RealtimeTransformRigidbody.OnLocalModelWillWrite is most expensive. A quick look at a deep profile sample shows some micro-optimisations which could shave a signficant percentage of the CPU cost of updating RealtimeTransforms.
From the call counts in this screenshot, you can see there are: 190 RealtimeTransforms 62 of those are RealtimeTransformRigidbodies 60 are syncing position, but none of them have moved (there's no model.set_position call) 62 are syncing rotation, but only two of them have rotated since the last update Some micro-optimisations i can see at a glance: The most expensive method is get_roomTime and the most expensive nested method get_realtime() is called twice instead of re-using the same realtime reference. Depending on the precision required, roomtime could be cached to a static field once by the first RT and shared by all RealtimeTransformRigidbody instances. In SetSafePosition and SetSafeRotation the models value is only set if the value is not equal and the new value is not NaN. In both cases, IsNaN is more expensive than IsEqual. Since conditions in if statements are evaluated left-to-right, changing the SetSafePosition if statement from "IsNaN or IsEqual" to "IsEqual or IsNaN" would allow non-moving RTs to exit without executing the more expensive IsNaN method.