Comment by robrtsql
8 years ago
Sure!
Hopefully a more experienced Godot dev will jump in and correct me if I'm wrong here..
Godot uses reference counting, but additionally supports a function which you can call on an object which will cause it to become 'unmanaged' by the reference counter, allowing you to free its memory on your own terms (or leak the memory, if you're not careful).
Godot 3.0 added support for Mono, but I'm not sure how that works. I'm guessing that game objects in Godot are still reference counted, but now you also have memory allocated by the Mono runtime which will be garbage collected.
Ironically, no amount of care towards memory management could approach even one tenth of the care and attention I'm required to devote to memory management in Unity (and, FWIW, also in actual Windows .NET) to avoid frequent dropped frames. This is exactly what I was hoping to hear, thanks!
Yep, I abandoned Unity after encountering the same issues as you. My experience is that every Unity GC run takes 10+ ms on my machine, even when there is no memory to clean up.
I tried MonoGame once and the results were much better--garbage collection was fast when there wasn't much to do. However, I'd still choose a non-garbage-collected engine any day because I dislike lag spikes.
While I hear generally about garbage collection causing dropped frames. I've had this happen to me in HTML5 land. I haven't heard about it as much with Unity, that C# was fast enough, and the under the hood pieces are C++ anyways. Perhaps I'm reading the wrong channels :). I'm curious if your game project is 3D, and what sort of intensity you tend to have with it.
It depends entirely on the details that affect the GC. The biggest factors are the size and structure of your heap data. If the game uses a lot of memory, the GC will try to collect more often. If the heap data is large and graph-like (lots of refs to refs), it takes longer to walk.
From: http://docs.godotengine.org/en/3.0/getting_started/scripting...
' Memory management
If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references. '
Reference counting is a form of garbage collection. And depending on your usage patterns it might not even be the fastest one.
Lots of increments/decrements on the refcount interleaved in normal code can kill the gains over a traditional GC that has nearly free allocation, batched finalizations and doesn't pollute the instruction stream with increments/decrements.
Also with a traditional GC you pay nothing if you don't allocate memory; the collector will never run. You still pay the full price of reference counting no matter if you're done allocating or not.