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.