With the Unity 5.1.1f1 Editor Profiler, my game is seeing very high CPU utilization from string logging in NetworkIdentity.UNetStaticUpdate, even though I have our NetworkManager log level set to Fatal (the least verbose level). I do not see any logs in the console while I see these big purple spikes in the image:
is there anything in the editor log file?
does this only happen in the editor? or also in remote profiler sessions for a stand-alone player?
can you get more detail with Deep Profile, or Profiler Editor?
Deep profile gives less info, as LogStringToConsole appears on a line by itself. I will have a look with the other methods.
Occurs in standalone build too. If I watch the output_log.txt for the standalone before and after a huge purple spike as in the picture above, there is only one warning print, and it is not from the networking code.
If you turn the log level back from Fatal to Debug, does it spam the log?
no
Check the Network panels in the profiler, they may show if any network activity is happening.
UNetStaticUpdate is the entry point for all HLAPI network message processing, and also for generating object state updates on the server. The function itself doesn’t do any logging or string formatting, so I’m not sure how the profiler got that result. It could be code in a message handler, but it is odd that the profiler doesnt have a stack strace for that.
I have the same problem in Unity 5.3.4f1 when profiling in editor and standalone build on Windows 10. CPU spikes related to LogStringToConsole start happening right after I connect client to the host.
1 Like
I had the same problem.
Yes, the UNetStaticUpdate itself doesn’t doing any logging to console - You Do.
To UNetStaticUpdate (looks like) belongs all networking things, like SyncVar/List hooks, Commands, Rpcs and etc.
So if you are doing any logging in yourself written functions, whose rely on UNET, then it counts as UnetStaticUpdate.
Just remove any logging…
Would you please explain that in English (how exactly to do that) ?
Just don’t use Debug.Log (or any other Debug.x), especially in methods, that are repeating more than 1 time per sec.
And if we are talking specifically about UNetStaticUpdate, then don’t use Debug.Log in all methods, that refer to Unet.
So, if your class inherits from NetworkBehaviour (for example), then it refers to Unet update.
Also, if you are using Synvar hook, that contains callback, then all Debug.Log inside that hook method also will be Unet update.
Should not the Unity handle this by itself ?
Do you think so ?
All these Debug.Log are written by you, so just take in mind, that each call of Log() is time! 