koobas.hobune.stream
Total memory allocated increases indefinately from .80GB untill crash
In the profiler, the mermory section displays that the total allocated memory keeps increasing over time. This happens very slowly and I manually recorded the total allocated memory at different times. Over a period few hours the total allocated memory increased from .80Gb to over 1.2GB.
I let the profiler run over night, and without any input at all to the game the total allocated memory was at 2.35GB. Also, the time it took all scripts together on an average to process at the CPU had increased from 3-4ms to around 12-15ms.
The reason why I started to profile the game over extended periods is because I noticed that FPS was dropping after just an hour of playing the game.
Why would this happen?
That sounds like you are allocating a resource (like an object, array, or other asset created at runtuime) and not releasing/destroying it. Look in your code for "helper" objects or arrays/lists that may not be getting destroyed...
You should be watchful for operations such as creating arrays or large objects without removing references to them, or you could end up with memory pooling. Be watchful of adding stuff to event handlers and never removing them or they will sit in memory for the duration for the program.
Also you should be wary whenever you create a resource as a mesh, a texture, gameobjects, or other resources as they will pile up unless you destroy them manually.
If you would witnessed an increase of memory usage from 0.8 GB to 2.35 GB over a period of 8 hours, it would mean it allocate 198.4 MB every hour or 3.3 MB every minute. That is 56.4 kB a second! If your game would be running at 60 fps, we're talking about 963 bytes garbage per frame being produced. Of course, it doesn't have to mean it's produced every frame, but it's just an approximate figure.
If I were you, I'd check any function that allocate memory, add stuff to lists, dictionaries, or other containers. I'd check every resource allocation, and all event registration (if you use events). It could be an extreme case of the garbage collector not collecting discarded objects, but I find that quite unlikely. You could periodically call
GC.Collect();
(like once a minute) to see if that stops memory usage from growing. If it does, I wouldn't worry too much as the garbage is bound to be collected whenever there's a need to release memory. However, it is an indication you are probably generating more garbage than you ideally should, and this is going to bounce back at you once the garbage collector is going to collect - in a nasty performance spike.
If it doesn't reduce memory usage, you are pooling managed memory or leaking unmanaged memory. Again, remove objects from event handlers. Make sure any collections doesn't grow indefinately. Make sure you don't create new meshes/textures/game objects etc without destroying the old. Be watchful about static lists or anything like that which never clears. Make sure you don't create huge strings by appending information each frame (causes garbage + allocations).
It's extremely hard to pinpoint the cause without going through the entire game. You could selectively rule out scripts by disabling them completely until you notice memory consumption no longer pile up. Once you have identified the script which is causing the problem, thoroughly go through every line of code and any calls that the script does.
Finally, make sure nothing stupid such as spamming the log with debug messages ain't happening (that consume memory too!)
$$anonymous$$y bet is it's the unity objects rather than mono ones, but who knows, +1 anyhows
Oh, right, since you eventually crash it's most likely memory pooling/native leaking. Garbage collector ought reclaim any stale memory before any crash occur.
Also, if you happen to have any native code, look there first.
yeh i get that too, i think it's the temp files. when you open a project notice a temp file is created within the project folder this will most likely hold stuff like undo and redo options with objects' transform position e.c.t
so after an hour or two if this file can get big! just reboot unity and you essentially refresh the file.
if you build and run the game this is not the case so don't worry about your finished game lagging after an hour of play because it won't have this temp file.
I'm having the same problem.
However, the memory "leak" does not occur when running outside of the Editor (Windows and Android). I noticed the memory leak is also slower on the Mac. I did not test on iOS as I've yet to fathom xcodes tools but suspect it's okay too. I did not try webplayer or Flash export but by this point I begun to look elsewhere for the leak.
I have used System.GC.GetTotalMemory to try to get an idea how much my C# script is using, this stays fairly constant but with only 2mb returned it's not taking into account any of Unity's memory needs (e.g. creating lot's of mesh colliders did not increase the memory usage in C#).
I therefore conclude that this leak is entirely within the editor. It may not necessarily be a leak either - perhaps just the way Unity manages it's memory, not cleaning up after itself until you stop Play as it knows most game sessions in the editor are short. Another reason may also be due to internal Unity logging, or even the profiler itself.
