Netcode for GameObjects is a high-level netcode SDK that provides networking capabilities to GameObject/MonoBehaviour workflows within Unity and sits on top of underlying transport layer.
MIT License
2.1k
stars
430
forks
source link
Unnecessary GC in Multiplayer Tools & Unity Transport #2896
Using 2.0.0-exp2, I've noticed that there's some GC as soon as Multiplayer Tools package is added.
The profiler indicated this begins in the Unity Transport class of NGO itself, so I locally imported Netcode for Gameobjects 2.0.0-exp2 & Multiplayer Tool packages.
The issue happens in two primary spots that I can see so far:
Issue 1:UnityTransport.ExtractNetworkMetrics under #if MULTIPLAYER_TOOLS_1_0_0_PRE_7At:com.unity.netcode.gameobjects\Runtime\Transports\UTP\UnityTransport.cs
The line that causes garbage allocations seems to be var ngoConnectionIds = NetworkManager.ConnectedClients.Keys;
This seems to be unnecessary for NGO 2.0.0 and up, because NetworkManager.ConnectedClientsIds (a list as opposed to dictionary) is available and now exposed to clients as well as servers, and can be iterated without GC alloc using the count and index access.
Issue 2:Ngo1Adapter.RefreshClientIdsAt:com.unity.multiplayer.tools\Adapters\Ngo1\Ngo1Adapter.cs
Granted, the name implies that NGO 2.0.0 and up would get its own adapter, eventually, I still think this is worth reporting.
This one also drops a clue that the package based itself explicitly on the fact that NGO1 limited access to connected client IDs and the multiplayer tools package was hacking access to them, understandable through this comment // NetworkManager.ConnectedClientsIds is only available on the server.
The faulty line is with using foreach (var clientId in m_NetworkManager.ConnectedClientsIds), and further down with foreach (var clientId in m_NetworkManager.SpawnManager.OwnershipToObjectsTable.Keys)
Once again, can be swapped to Count and index iterations. Can probably be unified for NGO 2.0.0 and up as well since Distributed Authority would not make use of IsServer, and both sides have access to ConnectedClientIds anyways.
Reproduce Steps
In a new project, import NGO 2.0.0-exp2, Unity Transport, and Multiplayer Tools packages.
Create a new scene
Add a network manager, make it use unity's transport
Add any way to begin hosting
Open the profiler, and enter playmode
Witness that UnityTransport.cs is allocating memory every frame
Witness that NGO1Adapter is allocating memory every frame
Actual Outcome
The two classes allocate memory every frame
Expected Outcome
The two classes don't allocate memory every frame (or at all - It is entirely possible to reach a stable 0GC alloc with NGO~)
Environment
OS: Windows 10
Unity Version: 6000.0.0b13
Netcode Version: 2.0.0-exp2
P.S Is there any proper place to report issues regarding the Multiplayer Tools pacakage? since its not part of this repository, but I couldn't find any official public repo for it specifically.
P.P.S Thank you very much for the frequent responses to the issues! I'm loving the activity visible around the Multiplayer Packages and hoping to help!
Description
Using 2.0.0-exp2, I've noticed that there's some GC as soon as Multiplayer Tools package is added. The profiler indicated this begins in the Unity Transport class of NGO itself, so I locally imported Netcode for Gameobjects 2.0.0-exp2 & Multiplayer Tool packages.
The issue happens in two primary spots that I can see so far:
Issue 1:
UnityTransport.ExtractNetworkMetricsunder#if MULTIPLAYER_TOOLS_1_0_0_PRE_7At:com.unity.netcode.gameobjects\Runtime\Transports\UTP\UnityTransport.csThe line that causes garbage allocations seems to be
var ngoConnectionIds = NetworkManager.ConnectedClients.Keys;This seems to be unnecessary for NGO 2.0.0 and up, becauseNetworkManager.ConnectedClientsIds(a list as opposed to dictionary) is available and now exposed to clients as well as servers, and can be iterated without GC alloc using the count and index access.Issue 2:
Ngo1Adapter.RefreshClientIdsAt:com.unity.multiplayer.tools\Adapters\Ngo1\Ngo1Adapter.csGranted, the name implies that NGO 2.0.0 and up would get its own adapter, eventually, I still think this is worth reporting.This one also drops a clue that the package based itself explicitly on the fact that NGO1 limited access to connected client IDs and the multiplayer tools package was hacking access to them, understandable through this comment
// NetworkManager.ConnectedClientsIds is only available on the server.The faulty line is with using
foreach (var clientId in m_NetworkManager.ConnectedClientsIds), and further down withforeach (var clientId in m_NetworkManager.SpawnManager.OwnershipToObjectsTable.Keys)Once again, can be swapped to Count and index iterations. Can probably be unified for NGO 2.0.0 and up as well since Distributed Authority would not make use of
IsServer, and both sides have access toConnectedClientIdsanyways.Reproduce Steps
Actual Outcome
The two classes allocate memory every frame
Expected Outcome
The two classes don't allocate memory every frame (or at all - It is entirely possible to reach a stable 0GC alloc with NGO~)
Environment
P.S Is there any proper place to report issues regarding the Multiplayer Tools pacakage? since its not part of this repository, but I couldn't find any official public repo for it specifically.
P.P.S Thank you very much for the frequent responses to the issues! I'm loving the activity visible around the Multiplayer Packages and hoping to help!