Possibly some kind of leak on Safari?

Bugs
1

This is going to be hard to make a repro for considering how much going on when our app booting up. I could use someones opinion on what’s going on here though.

Below are two performance screenshots showing Chrome vs Safari at the exact same point in our app when the loading screen is ready for them to enter.

Chrome:

Safari:

We make 300 materials for a pool, is it possible these are causing this extra bloat on safari somehow ?

2

I would guess so as they might be on the GPU thread in Chrome ?

3

If I kill off the pool, the “string” is down to 146mb with just two background meshes loaded. Is there anything that can be done about this or kind of at Safari’s mercy ? :confused:

4

Not sure tbh but I really wonder why there are so many :frowning: if you only have 2 materials.

5

Even an empty PG is taking 700mb in Safari where Chrome takes 40mb.

6

Empty Three in Safari

Empty Babylon in Safari

Screen Shot 2021-10-07 at 1.51.51 PM
Screen Shot 2021-10-07 at 1.51.51 PM996×396 30.5 KB

7

There is smthg terribly wrong here. I do not see how it is possible that a library less than 5Mb could end up expanding to 734Mb … This sounds insane ?

8

Maybe someone else with a mac can try as well just to make sure

9

@Cedric / @bghgary anything in JavascriptCore which could explain ?

10

No idea at all :confused: Can it be some strings not explicitly disposed in shader compilation that would be GC much later by JSC?

11

not constructive but Safari is a shit show :wink:

2 Likes
12

I appreciate that, nice knowing we all here w/ it :smiley:

13

can you check what is the memory profile occupation with an empty pg? we should have 1 or 2 shader string at max

1 Like
14

But it should be tried on a full.html without Monaco getting in the way :slight_smile: as I suppose intellisense might be string intensive

15

correct. Monaco could be a good culprit

16

Ah yes, those recent screenshots above were the PG vs online Three editor.

17

We should compare comparable situation like a default one sphere scene without anything else on screen so that we at least know for sure nothing is impacting the values.

You can try this in babylon Babylon.js Playground

18

Can Do !

figured might be helpful to see the path on one of these strings…

19

This sounds correct to me considering this page is having loaded all the BabylonJS scripts with all the existing materials.

The only weird par is how can those strings be that big in js memory but not in the sources.

20

Is it not weird too that Three’s retained size is 450kb for string in a similar complexity scene vs 20mb?