Possibly some kind of leak on Safari?

Bugs
21

So here you have the full babylon bundle with all the materials and everything whereas in three you might look at a bundled app relying on only one material which could have a huge impact.

That said, 20Mb of retained strings is still extreme

22

Ah okay, that makes sense. Though their editor does seem to have a lot loaded to begin with:

let me know if I can help testing anywhere else

23

right I ll have a look shortly to see if there is an easy culprit

24

Here is what I am seeing

image
image942×206 32 KB

It sounds more than accurate considering We have all our scripts loaded including the inspector and so on.

I tried a smaller version, take the previous pg save it locally and in the script references remove everything but Babylon. Close Safari to not keep previous snapshot data in. Open the page and make a snapshot.

You should see this:

image
image946×306 46.3 KB

With a total 16 Mb footprint:

image
image730×396 30.6 KB

This sounds pretty close from what I would expect considering the large size of the lib when relying on the bundle.

26

Hi all. Funny thing.. 4 years later and guess what we’re seeing something similar. Same code/same operations , note the heap growth in safari ( 16.6) where as chrome stays stable. This thread was fascinating but im unclear as to if there was a conclusion outside of the fact that safari is a $hitshow.

right now im trying to double check and make sure all our listeners are disposed. We are disposing the scenes first and then the engine like this. For this test, we only have one scene (though our system supports multiple scenes).

  

  function disposeEngine() {
    if(!engine) return;
    return new Promise((resolve, reject) => {
      engine.onDisposeObservable.addOnce(()=>{
        resolve(engine);
      });
      engine.dispose();
    });
  }

ps: for the below screenshot, we are essentially disposing and reloading the same scene over and over again. Chrome seems to be freeing up heap as id expect.

heap-chrome
heap-chrome1920×880 186 KB

heap-safari
heap-safari1920×1061 124 KB

27

It looks like the memory profile @srzerbetto mentioned in a meeting some days ago. Chrome is more reactive than Safari when dealing with garbage collector and memory deallocation.

28

I tried this on my iPad pro as well and its doing the same thing. I thought it was dev tools being buggy, but Its a legit thing because after several re-loads of the asset the browser finally crashes. Now here is whats REALLY hilarious, I tried profiling just a random webpage like.. google or something.. (non webgl) and im ALSO seeing the same issue of the heap slowly creeping up. Yep..these are my favorite kinds of problems. :frowning: :angry: In my Pro max im on IOS 16.1.1 on my ipad im on ipadOS 8.7.1 and MacOS is 15.6.1 (sequoya) running safari 18.6. On all devices I see the same thing. Ive tried scouring the apple dev formums for some solid answers but everyone says “you have a memory leak”. And yea, I tried to make sure engine.dispose is called and even then Ive done everything I can to clean up all the event listeners. Our applications are all VUEjs driven too.. havent seen if vue is doing anything bad yet.