-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculatation of sync on properties, relatively expensive #19535
Comments
This doesn't make sense to me: the Is all the overhead due to the sync machinery having to deal with a property rather than a field? |
It seems the ~0.7% is typical for each/more properties. So then it is not related to the/this specific properties. These traits show during an early stage of replay. On the shell map they different. See the three examples below. The other traits do not show up when I profile at max frequency. Seem they do not get sampled.
Later in game, 6 bots fighting:
|
or caching it doesn't sound like a good idea. It is the only way to get details from the state during desync investigation. |
Version: Bleed.
0.6% of all time spent in calculating sync hashes - across all game sync objects - is spent in calculating the sync hash for property
QuantizedFacings
ofBodyOrientation
objects. This is the most time spent across all sync objects.Request:
Pleas optimize this.
Possible solution:
Lazy<>
evaluation.In general it could be a good idea to look at all Sync properties to determine the expense of their Get methods. Ideally you don't want to calculate Syncs over properties - but rather fields. The sync will cause the possibly expensive calculation to be re executed once more.
Perhaps the game could log in debug mode those properties - that have a sync attribute - that take over x millisecond to calculate. Or better a code analyzer tool could inspect on the complicity of a get-er. This could be an indicator of Sync calling expensive get-ers.
The text was updated successfully, but these errors were encountered: