You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_7 At: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.RefreshClientIds At: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!
The text was updated successfully, but these errors were encountered:
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.ExtractNetworkMetrics
under#if MULTIPLAYER_TOOLS_1_0_0_PRE_7
At:
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.RefreshClientIds
At:
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 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 toConnectedClientIds
anyways.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!
The text was updated successfully, but these errors were encountered: