[???] GC can't keep up while the game is paused

[randi]

Please provide steps for reproducing. The GC should be able to handle anything without you having to adjust your code.

[Graf Zahl]

Using the version I downloaded when testing it the GC managed to keep memory in check. It had to fight for sure, but it always entered the pause stage again in-between and overall allocations remained constant. Yes, that's the one doing 4000+ allocations per frame.

[Player701]

This particular scenario is triggered when the game is not paused, but I'm pretty sure it's more or less the same issue. Whenever there is a scrolling animation active in my UI, there is a constant allocation of objects that store the position and size of the content that gets scrolled, so it is not possible to cache them. You can test it yourself with the PK3 here. Steps to reproduce:

1. Load up the Heretic or Hexen IWAD
2. Go to any map
3. Issue console command give artifacts
4. If the HUD is not visible, press "-" or "=" until it appears

Notice the title of the selected item above its icon in the inventory bar, scrolling back and forth. As long as it is visible and scrolling, the memory usage is constantly increasing. Pausing the game or disabling the HUD stops the animation, and the memory usage then stabilizes (although it does not seem to go down immediately, probably kept in reserve for new allocations). The animation speed is currently dependent on the frame rate (something else I wanted to address but haven't gotten to yet) but even at 60 FPS it is still fast enough for the problem to manifest.

[randi]

It looks like you have a memory leak related to the scrolling text. This isn't a case of the GC not keeping up. Do gc full a few times, and you'll see that the amount of used memory is rising.

(Also, in case you didn't know, the inventory bar isn't centered at ultrawide resolutions.)

[Player701]

Wow. Didn't know that would even be possible. Thanks, I'll check it out.

(Also, in case you didn't know, the inventory bar isn't centered at ultrawide resolutions.)

This may or may not be intended behavior, not sure because it's been a while since I touched the actual layout code. Thank you for telling me.

UPD: Funny story, this seems to be caused by Console.Printf that I put there for debugging purposes. It is called when a certain array, which is used for caching, is resized - and it happens very often during scrolling because the cache gets invalidated constantly. Commenting this call out seems to avert the crisis, at least with the new build. Could it be a case of "don't do that" because there really was a shit-ton of print calls there, or is this actually another bug?

[Graf Zahl]

Console.Printf should be harmless. It doesn't do any persistent internal allocations that may stick around.

[Player701]

And yet, removing this call seems to fix the issue for me, confirmed both by stat gc output and by memory usage in Task Manager. I haven't run a relatively long testing session yet but the difference is very much evident from the outset. You can test it yourself by commenting out line 173 in classes/wl/framework/caching/WL_DrawStackCacheWrapper.zs.

[randi]

It's likely just the retained console output.

I should probably also point at that, as counterintuitive as it might seem, the point of the garbage collector is not to quickly dispose of the garbage. The point is to be as unobtrusive as possible so you don't get big frame time spikes every time it takes out the garbage, and all that matters in that regard is that it can get rid of it faster than it's being generated. It's much better than before now. (Which is easy because it was completely broken.) But I also know it can be further improved since it still has some difficulty with rapidly escalating garbage and eventually gives up and spikes at the end to finish it; I will have to give it more thought to decide how best to deal with that.