Please fix the memory leaks

[navigator4223]

Seems like the GC is kicking in like crazy after some time in the game, even on machines with 32GB of RAM.

My best guess is that a lot of event handlers with heavy heap congestion don't get released properly.

Why GC?

The pattern of the stuttering on my 5950X / 3090 machine is clearly telling me "whenever memory is allocated, the blocking garbage collector takes a turn".

Known issue with many C# based frontends, can be solved, though.

[PyroMonk]

some games are held together by duct tape, elmers glue, and a dream.

[Deo]

Unity is a clunky garbage engine, always has been. No game on Unity runs good - even Valheim, which has literally pixelated graphics. And considering the amount of analytics/logs/other shady stuff Unity engine is taking - dunno why game developers even using it.

[navigator4223]

Its just sad to see that a game like BG3 with MUCH more detailed graphics runs smoothly on both PC and PS5 for hours and hours while PF:WotR with graphics from about 10 years ago brings my highend rig to its knees after 1-2 hours.

Hard to play on PS5, btw, if anyone is wondering.

[jonnin]

garbage collection isn't memory leaking. Its perfectly normal recovery and release of acquired resources. Memory leaking is where you ask for memory from the system, stop using it, but never give it back, and then ask for more again for the same task, use it, but don't give it back... until there isn't any more to get! GC won't let you do that: when you abandon the last hook to the unused memory, it is marked to be returned and is returned when the GC runs.

If GC is done poorly, its slow -- same as if you did your home rolled memory manager wrong in a non-gc language like C++.
Doing memory correctly is one of the hardest challenges in performance code.

[navigator4223]

Originally posted by jonnin:

garbage collection isn't memory leaking. Its perfectly normal recovery and release of acquired resources. Memory leaking is where you ask for memory from the system, stop using it, but never give it back, and then ask for more again for the same task, use it, but don't give it back... until there isn't any more to get! GC won't let you do that: when you abandon the last hook to the unused memory, it is marked to be returned and is returned when the GC runs.

If GC is done poorly, its slow -- same as if you did your home rolled memory manager wrong in a non-gc language like C++.
Doing memory correctly is one of the hardest challenges in performance code.

Of course it is. I have implemented garbage collection myself as part of one of my compiler projects as well.

Problem is: many garbage collectors are implemented in such a way that when memory pressures rises it becomes blocking for every other thread - and in a non-recovering way, the .NET-garbage collector shows this behaviour, for example.

And from the behaviour of the game here I can clearly tell that there are memory leaks involved, because over time the blocking GCs are becoming more and more.

[kaymarciy]

Can you provide at least some proofs that you are experiencing memory leak other than "my guts tell me"? A snapshot from GC profiler or PerfMon graph or anything? For now you only make a rather serious accusation of memory leak based on "stutterings" that no onebody else experiences.

[navigator4223]

Originally posted by kaymarciy:

Can you provide at least some proofs that you are experiencing memory leak other than "my guts tell me"? A snapshot from GC profiler or PerfMon graph or anything? For now you only make a rather serious accusation of memory leak based on "stutterings" that no onebody else experiences.

Play for 4-5 hours (at most), act 4. You will see that the graphics stutters like crazy when an enemy dies.

I get this on both PC (both my PCs) and the PS5.

This is a clear sign of a memory leak which leads to the GC kicking in and performing a blocking garbage collection, a usual thing you get a lot when you are not careful in .NET applications, for example (event handlers, as I said before, are the worst culprit here).

Could also be LOH.

But alright, I guess memory profiling is the way to go. You're right there.

[jonnin]

I agree with most of that too, it DOES sound like the .net garbage. if it clears up on a game restart and reappears after a predicted time frame, that is also evidence of at the very least memory bungling whatever name you want to label it with. I am much more used to DIY C/C++ than GC do it for you languages .. I don't even know how you would profile the GC without the source code (?) in hand. But if you can...

Ive seen the game get weird after very long sessions as well. I am rocking 64gb, so I have yet to hit a stutter problem, but I have had it drop the escape->menu (still accessible via mouse, save and exit / restart works) and after a while some mouse actions (select a player, or select an attack to do only to have it not register the selected attack or player clicked on) stop working 100%.

I blame myself on that one, though. Games were not meant to run 12 hours straight, and my walk away and come back computer activities lately, where I just leave it running, are surely outside of 'normal' operating intentions of this software. When it bugs out, I restart it, takes only a few seconds. Its not the only game I have that can't tolerate long sessions... quite a few out there hate it when you do that. I am not sure its a crisis in need of urgent fixing :) but it would be nice if they did.

[pckirk]

Unity fixed 90% of the memory leak problem, in the update to the Unity Engine we got last year in that huge update patch. Be thankful that it is mostly fixed. but the game itself still needs some major work on re coding of game elements.