Loading time performance regression?

Ok found it!

@Leon: You can see with this PG (by switching between 4.2 and 5.4) that 5.4 is not slower (on my compute here); Babylon.js Playground (babylonjs.com)

5.4: (first pixel after 1.7s and gltf loaded after 1s)

4.2: (first pixel after 1.7s and gltf loaded after 1s)

@Leon What browser and OS are you using?

1 Like

Thanks for the playground.
This is very interesting.

I’m running a iMac pro from 2017
on MacOS monterey 12.3.1
on Chrome 101

Babylon.js v4.2.1 - WebGL2 - Parallel shader compilation
time1: 1.399999976158142
time2: 1603.3999999761581
time3: 4342.100000023842

Babylon.js v5.4.0 - WebGL2 - Parallel shader compilation
time1: 1.699999988079071
time2: 1335.199999988079
time3: 6888.199999988079

There is both a large gap between your times and mine, but also between 4.2 and 5.
:sweat_smile:

Just to make sure it wasn’t chrome that was causing the problems I ran it in safari 15.4 also with the following results:

Babylon.js v4.2.1 - WebGL2 - Parallel shader compilation
time1: 1000
time2: 1601
time3: 4805

Babylon.js v5.4.0 - WebGL2 - Parallel shader compilation
time1: 2001
time2: 2149
time3: 6435

I had some colleagues do run the tests also just to see the difference between windows an mac

Older laptop i7 2ghz, 16gb ram
Windows 10, chrome 101

Babylon v4.2.1
time1: 1.799
time2: 1881
time3: 5199

Babylon 5.4.0
time1: 4.700
time2: 3723
time3: 12057

New 3D rig with good perf
Windows 11, chrome 101

Babylon v4.2.1
time1: 1.200
time2: 843
time3: 2133

Babylon v5.4.0
time1: 1.300
time2: 1051
time3: 2457

Could it have something to do with parallel shader compilation and how it allocates resources, maybe it doesn’t work correctly on mac or ios?

There is another thread with a private thread (due to the asset) where there is an issue with the shader compile being much slower on Mac. This seems to only be for Chrome and not Safari though.

the time 3 requires to wait for network call so this is not really representative

you do not need for the same to be ready to start rendering (we simply do it to avoid popping)

also makes sure to run the tests 3 or 4 times (by hitting run) so you can compensate for network latency

Did the test on a different computer on a different network:
image
image

I opened the test, and waited for it to run one time, then pressed the play button, waited for it to load completely and did so three times in a row as the only chrome window open in incognito to not be influenced by anything else.

the resulting times are about the same for all runs

iMac (Retina 5K, 27-inch, Late 2015)
4 GHz Quad-Core Intel Core i7
32 GB 1600 MHz DDR3
MacOS monterey 12.3.1
Chrome 101

Babylon.js v5.4.0 - WebGL2 - Parallel shader compilation
VM46:7 time1: 1.199999988079071
VM46:11 time2: 1754.9000000059605
VM46:17 time3: 7189.300000011921
thinEngine.ts:981 Babylon.js v5.4.0 - WebGL2 - Parallel shader compilation
VM47:7 time1: 1.399999976158142
VM47:11 time2: 1457.5999999940395
VM47:17 time3: 7067.199999988079
thinEngine.ts:981 Babylon.js v5.4.0 - WebGL2 - Parallel shader compilation
VM48:7 time1: 0.5
VM48:11 time2: 1439.5
VM48:17 time3: 6879.799999982119

And for Babylon 4.2.1

Babylon.js v4.2.1 - WebGL2 - Parallel shader compilation
VM74:7 time1: 0.4000000059604645
VM74:11 time2: 1426
VM74:17 time3: 4648.5999999940395
babylon.js:16 Babylon.js v4.2.1 - WebGL2 - Parallel shader compilation
VM75:7 time1: 0.6000000238418579
VM75:11 time2: 1481.4000000059605
VM75:17 time3: 3636.800000011921
babylon.js:16 Babylon.js v4.2.1 - WebGL2 - Parallel shader compilation
VM76:7 time1: 0.5
VM76:11 time2: 1442.800000011921
VM76:17 time3: 3585.4000000059605

As you can see the last step is taking double as long in 5.4 as in 4.2

I understand it’s hard for you to do any debugging without being able to reproduce.

What I did was create a chrome performance profile, you should be able to load it into your chrome to see where all the time is being spent and maybe help us debug the issue.

Please let me know if there is anything else I can do to help :slight_smile:

Babylon slow loading on mac.zip (6.8 MB)

OK! I may have found the FREAKING culprit :slight_smile:
Still test disable meshes because gltf loaders them them on later by deltakosh · Pull Request #12487 · BabylonJS/Babylon.js (github.com)

I will share here a link for you to test very soon

2 Likes

@Leon can you try with this version?
Babylon.js Playground (babylonjs.com)

No, still same result. :frowning:

Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 1.4000000357627869
time2: 1361
time3: 6617.100000023842
Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 0.5
time2: 1286.300000011921
time3: 6577.5
Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 1.300000011920929
time2: 1321.8999999761581
time3: 6697.199999988079

Then I cannot help more
I got STRICTLY comparable numbers on my 3 computers

How is it on your windows machine? can we try to narrow it down to a simpler space (macos + chrome?)

On windows 11 with Edge:

Windows 11 + Chrome 101:
image

Win11 + Firefox:

All the tests on all the machine I have are kind of in the same ballpark for time 2 and time 3

MacOS Monterry + Safari
image

The only moment I can repro it is on MacOS + Chrome:
image

Regarding the repro on Mac + Chrome, I think @Anupam_Das posted a bug on Chrome bug list

@Anupam_Das: Do you mind sharing the bug link? We can probably all vote it up

@Leon: We isolated it to a webgl2 bug on Chrome for macOS

you can workaround it for now by disabling webgl2 on this specific user agent