Effective way to remove texture from memory

[Rafael Almeida]

Hi, I'm having a serious problem with the memory usage, sometimes it hits 2.6 GB and never goes lower. I have to load some textures that vary from 10 MB to 40 MB for each map, and I'm sure that when I'm switching between the maps this textures are not being removed from the memory, so the problem grows every time you switch the Maps.

To test the issue, I created a 186 MB image then I loaded it into PIXI and got a big black texture throwing a lot of WebGL errors, maybe because it's too big? Anyway, I noticed that the RAM consuption grows a lot on the task manager, so I started my attemps to remove it from there, but I could not do it. I tried to do the following:

texture.destroy(true);
texture = null;

But I got nothing, so I did this (to throw everything away):

for (key in PIXI.utils.TextureCache) {
	PIXI.utils.TextureCache[key].destroy(true);
}

But the memory still remains with the same size, so I tried to use the destroy(true) and after I run the GC, the RAM lowered a bit but I was still able to notice the 186 MB texture being loaded. What must I do to remove it from there?

[merachefet]

It's up to the browser when garbage collection runs and when memory needs to be freed up. Chrome in particular will hold on to a lot of idle memory just in case it needs it later. Are you seeing performance problems?

[xerver]

If you can support having all that memory allocated, then chrome will just leave it there because it doesn't see a reason not to keep using it for other things (allocation/deallocation are expensive operations). Best you can do is destroy (clears our references and GPU memory) and then lose all of your references.

You can also do a memory profile and see if you have any references laying around that is keeping that image alive longer than you think it is (not resetting the loader perhaps?).

[Rafael Almeida]

7 hours ago, merachefet said:

It's up to the browser when garbage collection runs and when memory needs to be freed up. Chrome in particular will hold on to a lot of idle memory just in case it needs it later. Are you seeing performance problems?

Not a lot of performance problems, just some lag from time to time, but it isn't really noticiable, what annoys me is the fact that the game is consuming more than 2GB and never desalocates it. No other game that I played barely reached 1 GB. I don't know if it matters but the game is running on NW.js.

4 hours ago, xerver said:

If you can support having all that memory allocated, then chrome will just leave it there because it doesn't see a reason not to keep using it for other things (allocation/deallocation are expensive operations). Best you can do is destroy (clears our references and GPU memory) and then lose all of your references.

I really can't force a deallocation? It will be in the map transfer so no lag will be noticiable.

4 hours ago, xerver said:

You can also do a memory profile and see if you have any references laying around that is keeping that image alive longer than you think it is (not resetting the loader perhaps?).

Do I do it with the DevTool of Chrome? I took a Heap Screenshot and didn't saw something really big allocated even after loading the big texture, maybe I just don't know how to use it.

[xerver]

Quote

I really can't force a deallocation? It will be in the map transfer so no lag will be noticiable.

Nope, welcome to dynamic languages. It is up to the VM to garbage collect stuff when it feels it is appropriate. All you can do is lose references so it has the ability to cleanup, but when it cleans up is 100% up to the VM. If you click the GC button in dev tools and it suddenly frees a ton of memory, then it is just because the VM decided not to free that memory and instead reserve it for future use. This is not uncommon.

Quote

Do I do it with the DevTool of Chrome? I took a Heap Screenshot and didn't saw something really big allocated even after loading the big texture, maybe I just don't know how to use it.

Yup, the important part of the Heap Snapshot isn't so much large allocations as it is leaks. Specifically things highlighted in yellow, or things between two different snapshots that shouldn't be there anymore after the first one. For example, load a map and perform a snapshot, then do some action in your game that should clear memory and take another snapshot. See anything hanging around when it shouldn't?

[Rafael Almeida]

On 31/01/2017 at 2:10 AM, xerver said:

Yup, the important part of the Heap Snapshot isn't so much large allocations as it is leaks. Specifically things highlighted in yellow, or things between two different snapshots that shouldn't be there anymore after the first one. For example, load a map and perform a snapshot, then do some action in your game that should clear memory and take another snapshot. See anything hanging around when it shouldn't?

After some tests I has able to remove the texture from the RAM but realized that the leak may not be related to it. I searched about the issue and did 3 heap snapshots, but I have no clue about what to do after that:

The game's RAM raised from 300 MB to around 900 MB and every map transfer allocates around 100 MB to 200 MB and it never goes bellow. I know that this objects are with their references kept somewhere, right? But is there some way to find where? Other question: if a variable that keeps an whole scene have children, after I do "this._scene = null" do I get rid of all the references that my children did or do I must assign every chindren reference to null too? Thanks for you help so far.

[xerver]

Quote

I know that this objects are with their references kept somewhere, right? But is there some way to find where?

That tree at the bottom labeled "Retainers" is telling you what is retaining that object.

Quote

Other question: if a variable that keeps an whole scene have children, after I do "this._scene = null" do I get rid of all the references that my children did or do I must assign every chindren reference to null too?

Hard to say with what you just described to me there, but you should be calling "this._scene.destroy(true)" most likely. Because otherwise references will likely be kept around.