Upgrading from 1.11.0 to 2.0.0 PostLateNetworkUpdate performance

[MadJones]

Description

I have a world of 400x400 tiles that is filled with Environment Objects such as trees. These are network behaviours with attached network object components. These generally get culled (set active/inactive) depending on player proximity. Generally this stops most updates from happening in 1.11.0. However in 2.0.0 according to the Profiler (see attached screenshot) PostLateNetworkUpdate has an immense impact on performance. Enabling/disabling the gameobjects has no influence on the performance. Only actually destroying the objects will improve the performance in 2.0.0. Looks like a bug to me, but I could be wrong and this is intended behaviour for some reason that I am not aware of.

Reproduce Steps

Upgrade from 1.11.0 NGO to 2.0.0

Expected Outcome

Similiar or better performance.

SCreenshots

1.11.0

2.0.0

If applicable, add screenshots to help explain your problem.

Environment

OS: Windows
Unity Version: 6000.0.20f1
Netcode Version: 2.0.0

Cheers

[NoelStephensUnity]

@MadJones

Based on your description, my guess is that:

• In v1.x.x each NetworkObject used the MonoBehaviour.Update to handle updating scene changed notifications for NetworkObjects, so by disabling the NetworkObjects you were stopping those updates/checks.
• In v2.x.x NetworkObject no longer uses MonoBehaviour.Update to handle scene changed notifications, and if you don't plan on any of the Environment NetworkObjects in question to change scenes (i.e. be migrated into a new scene) then you can un-check the Scene Migration Synchronization check-box which will not include those NetworkObject instances to check for changes in their scene during the PostLateNetworkUpdate.

This transition between the two versions was to provide a way to exclude that update without having to do any form of scene/distance culling for NetworkObjects that will never need to be synchronized when they are migrated to a different scene.

Check to see if they all have "Scene Migration Synchronization" enabled and if so disable this:

Then re-run your profiler and see if that looks more like what you are expecting.

Let me know if this helps?

If not, could you expand the profiler in v2.0.0 to see where the most time is spent?

[MadJones]

@NoelStephensUnity

Thanks, that fixed it for PostLateUpdate.

Out of curiosity, I also saw a lot of performance going into the Ngo1Adapter.RefreshObjectIds. Is there also a way to keep that under control by any means?

It seems to be part of the NetworkPreUpdate Loop.

Kind regards,

[NoelStephensUnity]

@MadJones
Good to hear that solved the first performance issue. I think we will make that property default to false/off as a QOL improvement in the next update.

Regarding the Ngo1Adapter, I believe that is part of the Multiplayer Tools package...
I did add some properties to NetworkManager to be able to enable/disable some of the processor intensive portions for profiling purposes:

But it would appear that I need to get with the tools group and see if we can provide a mechanism to disable that registration with the network tick event when there is no immediate need for it.

For now, I believe removing the Multiplayer Tools package (temporarily) should remove the Ngo1Adapter and it will no longer register for the network tick event.

Thank you for providing this feedback on your findings! 🥇
These are those little details that make all of the difference when developing. Will follow up on the status of making this more configurable (i.e. some form of property or API to disable the Ngo1Adapter for profiling purposes).
👍