Hi!
I can see in the Profiler that GUI.Repaint is allocating 1.4KB every frame.
Is there a way to fix this?
Is this a issue?
We have a memory leak. We have fixed some GCAlloc caused by update frames with strings, but we are unsure of how to proceed with this one, or even if it is an issue.
Thanks!
Well, do you use any IMGUI code in your scripts? In other words do you have one or multiple OnGUI methods anywhere in your scripts? If so, that’s the source for the allocations ^^. Since you asked how to proceed, you may want to enable deep profiling in the profiler and expand the node to see how it actually breaks down and which classes are responsible for that.
Note that the IMGUI system almost always allocates at least a bit of memory. Though some allocations can be avoided. Since we don’t know if you’re actually using OnGUI or if that allocations may come from the Unity editor UI we can’t really help you any further here. If you have OnGUI code, you should post that code.
I do have, in a couple of places, but does not look like I am doing any kind of allocations:
rivate void OnGUI()
{
_chat.BlockedEnterButton = EventSystem.current.currentSelectedGameObject &&
(EventSystem.current.currentSelectedGameObject.name == _inputField.name);
}
and
private void OnGUI()
{
if (_removeFocus)
{
EventSystem.current.SetSelectedGameObject(null);
_removeFocus = false;
}
}
Well, first of all nothing you have in OnGUI does belong in OnGUI. All the code you posted should be in Update. So just remove those OnGUI methods completely. Apart from that, if you really need to use the IMGUI system somewhere, somehow and you want to minimize the allocated memory, you should disable the layout system by setting
useGUILayout = false; in Start. Of course when you disable the IMGUI layout system you can not use anything from the GUILayout class, but it removes the allocation. Note that reading the gameobject’s name will actually allocate memory because the gameobject’s name is stored on the native code side of Unity. When you read the name or tag Unity has to copy the name into a managed string which needs to be allocated every time.
Since you use the gameobject’s name for comparison reasons, you may be able to store the name in a variable whenever the selection changes. This should minimize the allocations required.
As I said you can use the Profiler inside the Unity editor to monitor all that. With deep profiling you should see the exact stacktrace which part of Unity causes this allocation. When the layout system is active, you get a huge chunk through the internal call to GUILayoutUtility.Begin. Further more you should see your own script(s) as well and the “get_name” method should be there as well. Just expand all items that allocate memory.
“Note that reading the gameobject’s name will actually allocate memory because the gameobject’s name is stored on the native code side of Unity. When you read the name or tag Unity has to copy the name into a managed string which needs to be allocated every time.”
I had no idea about this.
Thank you so much Bunny83! I will give deep profiling a go and see what else I can understand/
Thanks!
Yes, those are the small unintuitive culprits you just have to remember ^^. Thankfully for comparing the tag we have the CompareTab method. Using that does not allocate memory since it goes the opposite way. So instead of transferring the unmanaged string into managed land, we take out managed string and pass it to native code where the comparison is made. Since native code can directly lookup the content of our managed string, there’s no need to allocate memory.
Unfortunately there is no such method for the name of a gameobject. Of course one solution would be to utilise the tag instead, of use your own identification string on a MonoBehaviour on that object. Well this is all only relevant if you need to keep the GC as low as possible which may be relevant for mobile games.