Analyzing memory leaks


We are testing out some things in Babylon.js and many times we end up in situation where task manager shows Chrome eating many gigabytes of memory all the way until 20 GB! But JS heap stays under 100Mb. We think this might be because memory gets leaked in the VBO buffers on GPU memory maybe? (In our test we do use lots of ImportMesh and mesh.dispose(true, true))

Have you guys ended up in the same situation? Would be nice to understand how to debug this kind of situations where memory is obviously leaked but JS side does not show any of that…

Some new observations:

  1. This “memore leak” happens only with Chrome console on! I quess it is because chrome is storing all the network traffic in the console’s network tab?

  2. Memory usage comes mostly from Typed Arrays like “new Uint32Array()”

I quess after all this might be more like a false alarm…

Console eats a ton of memory. Always good to have it closed when testing performance. I think those memory items are created by BabylonJS library at initialization. I have noticed them and did see another thread about a month back about this exact same thing.

Thanks for the toughts. We have looked into this same topic more and the Windows & Chrome environment seems to behave as expected now. Also on Windows Chrome can allocate many gigabytes of native memory without chrashing, so real-world applications can be implemented, which is a very good outcome! :+1:

Next we enter the iPhone environment which is really the relevant case for the memory analysis. There we do face the browser crash again as soon as enough meshes have been imported. We will now try to see if Safari memory anaylisis reveals something.

In general we think that Babylon.js (and webgl!) are quite difficult to handle when it comes to memory management. In the end we will also need some way to check “how much memory we can safetely use”, and this might be almost impossible with current webgl…

Final observations:

  1. Be carefull with Chrome console. It will consume lots of memory if there are many network requests that get stored in the network tab.

  2. TypedArrays like Uint32Array do not show properly on JS heap. Those have to be analyzed in a special way… maybe by comparin heap snapshots.

We did not find any bugs in Babylon.js regarding this for now.


stats.js might be a useful tool, as shown in the top left corner. Blue is FPS, green is render time per frame, red is memory.

I spent the first few seconds generating a lot of cubes without deleting them from the Map they were put into (and without running mesh.dispose()). The memory rose from 35 MB to ~1 GB. After stopping generating cubes, the FPS rose back to ~60 and the memory leveled off.