Loading time performance regression?

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

1267322 - [WebGL 2] Seeing stalls in getUniformBlockIndex() despite waiting for program readiness with COMPLETION_STATUS_KHR - chromium

Please upvote!

3 Likes

@Leon we have a workaround in place that should fix EVERYTHING (and you can keep using webgl2):
Babylon.js Playground (babylonjs.com)

Please tell me what are your numbers now

5 Likes

I was able to test on my Mac too and got about the same results as your’s @Deltakosh, about a second with Safari and about 4 seconds with Chrome after testing several runs. And with your PR it’s down to about a second or faster on Chrome. :slight_smile:

I also tested on FireFox where it’s taking about 3 seconds. After copying your same exception but for Mac and FireFox it’s down to about a second too thou…

1 Like

Anyone’s ever noticed the weird behavior of Chrome on Mac? Sometimes clearing the cache or even restarting Chrome makes the loading about 20% faster (I’m not speaking about just bjs or webGL) this is even true with the bloody Apple website :wink: May be yours noticed that the same apple website actually loads faster with edge on Windows :wink: I don’t know what these Guys are doing to sell us a rig that is twice the price of its windows counterpart and leaving such parts (as WebGL) unattended for years, sometimes for decades. I have been a mac user for (well, since mac :wink: and I still like Mac and work on Mac (but then, I play on Windows :wink: I simply cannot endorse the way these Guys are doing what is supposed to be their job :unamused:

Hell Yeah! :champagne:
Now it feels fast again :slight_smile:

Thanks for the awesome work!

iMac Pro
MacOS Monterey
Chrome 101

Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 0.5
time2: 1200.8000000715256
time3: 1369.3000000715256
Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 0.5
time2: 1177.6000000238419
time3: 1375.1000000238419
Babylon.js v5.5.5 - WebGL2 - Parallel shader compilation
time1: 0.5
time2: 1276.6999999284744
time3: 1459.8999999761581
3 Likes