Bug Report: Memory Dump(?) issue

[TheStinkern]

What version of the engine are you using?

a6c24bb

Which target are you using?

Windows

Explain your issue

The memory does not clear when you exit PlayState.hx. It just stays. I'm not sure if this applies to every state or not.

Pre-PlayState (freeplay):

During PlayState (don't mind that it takes up 1.7 gigabytes 😭; in PauseSubstate):

Somethings also wrong with the text on the counter, its kind of fucked.

Post-PlayState (still freeplay):

Some sprites that were not loaded decides to return a haxeflixel icon after a certain amount of memory (maybe over 1.5-2 GB.

Heres a funny screenshot from the memory leak:

[r6915ee]

I think that in this case, it's probably caching in a lot of extra assets. FunkinCache works very oddly, as it maintains two separate "layers" to cached items. It will on occasion move items from the first layer into the second, and on state switches it will drop items in the second layer. I would imagine that FunkinCache may be managing the second layer awkwardly here.

If you're using videos, then that's probably part of the issue as well. You usually need to get rid of the video's memory when you're done using it (note the use of video.onEndReached and video.bitmap.onEndReached calling into different functions, depending on whether you're using FlxVideo or FlxVideoSprite).

That being said, if you've reasonably optimized your mod, then you usually shouldn't be able to get 200 megabytes in memory usage at all. Probably the first thing that comes to mind for optimizing it is running all of the mod's PNGs through something like optipng or similar, which in the case of optipng on default settings, will usually net you a 30% decrease in file size per affected file. You may also want to use the destroy method on FlxSprites that you don't need anymore.

[TheStinkern]

...You may also want to use the destroy method on FlxSprites that you don't need anymore.

Wasn't that done automatically?

[r6915ee]

Wasn't that done automatically?

I believe so, but usually you will probably want to do it either way in cases where you really need to make sure that later parts of the song don't use a lot of memory. It's not much of a costly operation; the only case I can think of where you need to be careful is whenever you're working with anything that has an animation that gets played on certain intervals (usually characters; the main cause of this will usually be the method calls involved, so looping animations are unaffected).

[TheStinkern]

I believe so, but usually you will probably want to do it either way in cases where you really need to make sure that later parts of the song don't use a lot of memory. It's not much of a costly operation; the only case I can think of where you need to be careful is whenever you're working with anything that has an animation that gets played on certain intervals (usually characters; the main cause of this will usually be the method calls involved, so looping animations are unaffected).

The memory wasnt that bad before updating to that commit. Its definitely something with CNE.

[r6915ee]

The memory wasnt that bad before updating to that commit. Its definitely something with CNE.

Hm, then it could potentially be related to this bug noticed in the Codename Crew Discord server, since you do seem to have the new Dear Imgui console open in one of the images. The thread in question talks about a similar memory issue that appears to be related to Dear Imgui.

[TheStinkern]

...since you do seem to have the new Dear Imgui console open in one of the images.

That was during the time we noticed the memory leak, which was about a hour before deciding to make this issue. I did open PlayState.hx and exit the state without the console, still the same. I don't think its something related to the console.

By the way, partially off-topic, this is what I meant by the HaxeFlixel graphic thing. Reproduced that part of the bug.

[r6915ee]

By the way, partially off-topic, this is what I meant by the HaxeFlixel graphic thing.

In regards to the HaxeFlixel icons in particular, you might want to check the console and see if it's propagating any errors about the graphics. HaxeFlixel will usually make it somewhat apparent why a graphic might not be loading correctly. It also should generally be able to handle the range of memory usage you specified in the original issue; I've seen a few mods in multiple engines be capable of (somehow) running in that range.

[TheStinkern]

In regards to the HaxeFlixel icons in particular, you might want to check the console and see if it's propagating any errors about the graphics.

Its not that. Its clearly the memory. As I've already said earlier, everything thats related to this has never happened before updating the CNE build.

[r6915ee]

My apologies on that; I should've probably mentioned how I needed to do something, so I only mentioned the HaxeFlixel icons (though, the console should still say why the graphic may have issues).

Back to the main issue, I ended up testing the way the memory grows with both a streamed instrumental and a non-streamed instrumental. Both tend to grow slowly over time, although this growth can slow down after consecutive playthroughs of a song. However, a large portion of what gets used still doesn't seem to be deallocated from memory. So I think that in this case, some assets are either being cached improperly, or they aren't picked up properly by the HXCPP garbage collector.

At the moment, I think the best course of action here would be to figure out where exactly their references are being stored, and remove them so the garbage collector removes the actual values. With all of the in-memory caches that Codename provides, the first ones that come to mind would be FlxG.bitmap (which Codename doesn't interact with very nicely in certain cases) and the various caches that are present in OpenFL and Lime.

[TheStinkern]

You do know that we are not trying to cache the sprites, right?

[r6915ee]

You do know that we are not trying to cache the sprites, right?

That I suppose would be true. The problem here is that most of the caching is generally opt-out because of default function parameters (for example FlxGraphic.fromAssetKey and its Cache parameter being set to true) in HaxeFlixel, and most of the methods the engine uses internally, such as something as basic as character creation, do not explicitly avoid this. The first thing that comes to mind with sprites is older versions of Paths.loadFrames, which had a side effect where it implicitly needed to cache and retrieve an additional graphic that held the linked frame collections when using multiple spritesheets under a single sprite, so that caused a problem with managing the cache in that any spritesheets that were destroyed needed to also have this additional graphic removed if they were linked (the extra graphic still contained references to the deallocated memory, even while it was cached).

[TheStinkern]

We are using all the basic things that CNE could provide us. I've said in the issue's description, "The memory does not clear when you exit PlayState.hx. It just stays."

The memory dump bullshit was already done before by the engine itself. We are barely even using FlxSprite (which is FunkinSprite), and we are not trying to remove the cached memory ourselves, that would take so long to do.

[r6915ee]

We are using all the basic things that CNE could provide us.

The example I've mentioned above with Paths.loadFrames already applies to basic things like stages and characters, because that same function is used for loading character and stage element spritesheets considering those two examples.

I've said in the issue's description, "The memory does not clear when you exit PlayState.hx. It just stays."

That would then be the references being kept alive, since the HXCPP garbage collector should be active by default. Generally, the garbage collector deallocates memory whenever there are no more references to it available. Storing something in memory for retrieval is something a cache is already intended to do under normal circumstances.

...we are not trying to remove the cached memory ourselves, that would take so long to do.

With sprites, you can usually use FlxG.bitmap.remove to remove their associated FlxGraphic from graphic cache.

[TheStinkern]

That would then be the references being kept alive, since the HXCPP garbage collector should be active by default. Generally, the garbage collector deallocates memory whenever there are no more references to it available. Storing something in memory for retrieval is something a cache is already intended to do under normal circumstances.

Check the code for it then. See if its doing what it should do.

[Raltyro]

Every assets now have a second change of lifetimes before getting cleared (triggers after assets not being used on state switchs twice), this is expected if thats what you meant