koobas.hobune.stream
Are there any known memory leaks in unity3d or mono?
Is there any mono or unity3d api call or language construct to be avoided to prevent memory leaks?
I am not talking about programming errors from us, unity3d users, like keeping references to lots of data thus preventing the garbage collection to work.
I mean the kind of stuff that is legal and should work just fine but due to known implementation bugs we must avoid.
there are not such api known but there are practices that you can do to make garbage collection faster and better.
- don't allocate memory (specially for large objects) in functions like Update because this will cause multiple allocation and deallocation.
- unity/mono's garbage collector is not an advanced one like what you have in .NET or java. it don't use generation based collection and different heap parts for different size objects. i don't know how much it improved for mono 2.6 but it not as good as .NET's GC.
- use GC.Collect() whenever you think you have time and allocated many objects that you don't use any more. why you should wait for the garbage collector.
- if you use unmanaged (native) plugins try to implement appropreate interfaces to unload resources properly.
memory for objects like meshes and textures will not be collected when you call GC.Collect(0); because they are not managed data and the managed apis just create them in unmanaged memory for you. if you want to know more about memory leaks that unity had before and solved. take a look at this page. i think there was not any. the mono version is too old but in 3.0 we will have mono 2.6 wich is a big improvement.
Good read up besides #3. GC.Collect should only ever be called as GC.Collect(0), especially in $$anonymous$$ono. On top of that, Texture2D memory is 99% in native memory, so garbage collection basically just reclaims a single, almost empty class
thank you mike. I'll edit it to correct my mistake about Texture2d but when i wrote GC.Collect() i just meant GC.Collect without any specification of empty parameter list or an special argument. i can not find any reason for GC.Collect(0) because mono don't use generations as i know. how can i remove the leaks caused by Texture2ds?
I have found unity memory leaks. One seems to be any creation of Texture2D objects. I worked around this by only creating them once, and using Resize() and SetPixels() after that.
I am also seeing memory that's never reclaimed in a function that modifies a large Color[] array, looping over it and manipulates each of values before it is set as the pixels of a Texture2D object (persistent).
I made a testcase and filed a bug today--in our actual game, the memory grows without bound. In the testcase, the Unity editor's memory grows without bound, but the standalone build gets to 435M and does not increase beyond that. Changing scenes definitely does not free the memory, because that is part of the test. The problem is more serious when the work is done in a separate thread.
UPDATE: The problem occurs whenever a temporary thread accesses non-static data members or functions. When this happens, all of the class's memory fails to be released when the class is unloaded in a scene change.
I am also experiencing memory leaks as well. Could you explain your update a bit more in detail? Does it include any type of C# classes or is it just Unity C# classes? The game my company is developing uses extra threads beside from the Unity main thread, so I am wondering if this can have something to do with it?
