Huge performance hit after upgrading from 3.1.0-alpha3.5 to 3.1.0-alpha3.7

[thrice]

Also here is screenshot of profile, all I did was pointer over a few cards to trigger hover states

[thrice]

Also in the comments of my profiling I did a count of materials .isFrozen, because that is a new property / optimization I hadn't seen before - Thought maybe it was recently added and all materials were frozen before by default. Anyways, I just did a 

_.invokeMap(play_game.scene.babylon.materials, 'freeze')

on all 600+ materials, and while it looks like frame rate bumped up SLIGHTLY (seems to be hovering around low 50's now), it is still much lower than the consistent 60fps when nothing is going on, that I see with the older RC version

[Sebavan]

Sharing a repro would really help as your perf or hit analysis do not help that much unfortunately.

lodash on top of it is definitely making it even slower. Is the FPS increasing a lot if you reduce your canvas size ?

[RaananW]

From the shared profiling I can't seem to find a problem. You even have 3 seconds idle time... Is there a different in the profiling between earlier versions to the current version?

[thrice]

10 hours ago, Sebavan said:

Sharing a repro would really help as your perf or hit analysis do not help that much unfortunately.

lodash on top of it is definitely making it even slower. Is the FPS increasing a lot if you reduce your canvas size ?

I'm not sure how lodash would make anything slower, its just a (heavily optimized), utility library, does not affect performance. I'm running those calls from the console, not like it's part of the render loop or anything.

-- Regarding the canvas size: Nope I tried that actually. Shrunk it to pretty much phone size, seemed to run about the same

[thrice]

2 hours ago, RaananW said:

From the shared profiling I can't seem to find a problem. You even have 3 seconds idle time... Is there a different in the profiling between earlier versions to the current version?

Well since the instrumentation stuff was added after the current version, it's hard to compare apples to apples. I'm going to go through and do the lodash counts on older version right now though to see if there are any discrepancies. 

Oh also, may be worth mentioning that I'm running my app with renderEvenWhileInBackground = false, I'm not sure if that has any affect on the idle time shown in the profiler or not (I clicked to debugger tools ,which freezes the app, started profile, clicked back into app to resume, and then triggered some hover states and what not)

[thrice]

For comparison, here are the counts from the 60 FPS 3.1.0-alpha3.5 version: - Summary: there are actually slightly fewer meshes/materials active in the newer version - but also, in the newer version, you'll note that there are 487 meshes enabled, versus 616 in old version. So if anything you would think it would be rendering faster.

The one and ONLY count that appears higher in the newer version, is count of undefined meshes in the _activeMeshes.data (23 versus 11)

So, this furthers my belief that some change in the library itself is causing the slower performance. 

_.groupBy(_.map(play_game.scene.babylon.meshes, 'isWorldMatrixFrozen'))
Object {false: Array[466], true: Array[1443]}

_.groupBy(_.invokeMap(play_game.scene.babylon.meshes, 'isEnabled'))
Object {true: Array[616], false: Array[1293]}

_.groupBy(_.map(play_game.scene.babylon.meshes, 'areNormalsFrozen'))
Object {false: Array[1313], undefined: Array[596]}

_.groupBy(_.map(_.compact(play_game.scene.babylon._activeMeshes.data), 'areNormalsFrozen'))
Object {false: Array[91], undefined: Array[154]}

play_game.scene.babylon._activeMeshes.data.length
256

_.filter(play_game.scene.babylon._activeMeshes.data, _.isUndefined).length
11

_.groupBy(_.invokeMap(_.compact(play_game.scene.babylon._activeMeshes.data), 'getClassName'));
Object {Mesh: Array[91], InstancedMesh: Array[154]}

_.groupBy(_.invokeMap(_.compact(play_game.scene.babylon.meshes), 'getClassName'))
Object {Mesh: Array[1313], InstancedMesh: Array[596]}

play_game.scene.babylon.materials.length
712

_.groupBy(_.invokeMap(_.compact(play_game.scene.babylon.materials), 'getClassName'))
Object {ShaderMaterial: Array[7], GradientMaterial: Array[1], StandardMaterial: Array[702], PBRMaterial: Array[2]}

_.groupBy(play_game.scene.babylon.materials, 'isFrozen')
Object {false: Array[712]}

 

[Sebavan]

Can you compare both Chrome profiling session ? This would help narrowing down the issue. 

[thrice]

Profile from alpha version - I'm not entirely sure what to make of it though. Seems like cpu issue if I'm reading it right, but still unsure as to why. And also if I'm reading it right, render % seems lower, which would lead me to believe it should actually be performing better. 

 

[Sebavan]

As the fps does not change with resize it usually a proof that the bottleneck is on the cpu side.

Could you share your perf analysis (ctrl+s from the analysis result page to store in json) one in the old version and one in the new version ?

This way we could all dig in the comparison.

Thx.

[thrice]

On 11/30/2017 at 10:30 PM, Sebavan said:

As the fps does not change with resize it usually a proof that the bottleneck is on the cpu side.

Could you share your perf analysis (ctrl+s from the analysis result page to store in json) one in the old version and one in the new version ?

This way we could all dig in the comparison.

Thx.

That's a good point. I will try to find time to switch back to newer version to get the output in next couple of days.

In the meantime, I may or may not have noticed something that could be helpful in terms of reproducing.

The sponza demo scene https://www.babylonjs.com/demos/sponza/ , is running for me at < 10 FPS consistently. I don't ever recall seeing it that low in the past, perhaps it is suffering from the same issue(s)? Also, the resize behavior you pointed out is consistent with that scene as well, if I shrink the window down super small, FPS not changing. Consistent < 10 fps

[GameMonetize]

Can you run a profiler on your browser to see where the perf is going?

[thrice]

13 minutes ago, Deltakosh said:

Can you run a profiler on your browser to see where the perf is going?

On the sponza scene? sure.

https://www.dropbox.com/s/ge6mc8olk4nsly8/sponza_lte_10fps_Profile-20171218T145557?dl=1

[GameMonetize]

Can you share screenshots?

[thrice]

18 minutes ago, Deltakosh said:

Can you share screenshots?

Of the profile output? Sure but I'm no expert at interpreting the output, and not entirely sure what normal looks like. Here are some shots of what appears to be relevant. One thing that does seem curious is on the line graph, there does not appear to be a line for GPU memory as far as I can tell. Also the warning on the animation frame fired / recurring handler. -- it does seem consistent with the behavior I am seeing in my electron app (mostly doing nothing, and fps is < 60, well in this case < 10 fps). Also worth noting that when I had my app upgraded to the newest version, I ran it on my laptop (new macbook pro), to make sure it wasn't a computer thing/setting. Performance was consistent with my current computer (2015 iMac).

-- And I just ran sponza on my macbook pro also to make sure, performance is < 10 FPS there as well. Are you guys not seeing < 10 FPS ?

[MackeyK24]

Hey @Deltakosh im in the same boat and i dont know how to really interpret the profiler to be able to pin point what the problem is. All i can say for sure is, i had the space shooter demo going (you saw it). That demo is using 3.1 alpha. That demo is use Cannon Physics for EVERYTHING... all the player, enymnet and laser bolt movements, all the the collision detection, basically the whole game. But when i updated to 3.1 beta (or greater). All the stuff using cannon physics is just dog slow. Like my asteroids falling is just WAY slow, collision are not happening (some are, but most not). It just really funky... I will put up another demo of the same game but using the latest babylonjs... Maybe you can tell with the profiler.

It does not give any errors is just kinda funky...

Here is the first Space Shooter 3.1 Alpha works great...

Now here is same game with updated BabylonJS: Space Shooter 3.2 Alpha

Please see if you can tell what is going on... Or anyone else who might have some insight

 

[Pierre Glibert]

Hello everyone

I read something this morning : https://github.com/pissang/qtek-model-viewer.

So, I decided to test it with " Adam head " ( https://sketchfab.com/features/gltf) on https://pissang.github.io/qtek-model-viewer/editor/

I saw that it run with postprocesses perfectly on Sketchfab and QTEK-model-viewer but not on Babylon sandbox WITHOUT postprocesses ... (4fps  )

When I inspected, I saw that response of GPU is 10x bigger on babylon than QTEK-model-viewer ...

 

• QTEK-model-viewer (with occlusion and glow posprocesses):

 

• Babylon sandbox (without postprocesses):

 

@Deltakosh, maybe you can easily test it with this model as a reference to find where our favorite engine drop

I hope this post will help you.

have a nice day,

Pierre. 

 

EDIT : 

Tested with battle " damaged helmet " :

• QTEK-model-viewer ( without postprocesses ) :

 

• Babylon sandbox (without postprocesses):

With this model, frames rate is the same 

 

"Adam head" work with PBRSpecularGlossinessMaterial and  "damaged helmet" with PBRMetallicRoughnessMaterial. 

You can see it when you click on the mesh in GLTF viewer ( qtek-model-viewer )

 

[GameMonetize]

I cannot repro this.

Can you make sure there are no error in the console when you load the Adam head model?

[GameMonetize]

ok it is a bug when drag'n'dropping folders in the sandbox  Will fix it ASAP and report here

[GameMonetize]

Ok fixed!!

Thank you so much. It was a really weird bug. You can test it now

 

thanks again, it was really an interesting bug

[Pierre Glibert]

The bug persist ... 

It's weird because sometimes it show nothing and show me this in console : " Please provide a valid .babylon file. "

Or it render the model but not with all textures... 

 

or this :

 

[GameMonetize]

Clear your cache

[Pierre Glibert]

thanks @Deltakosh.

I will write a new post because i see some trouble on gltf render

 

[thrice]

3 hours ago, Deltakosh said:

ok it is a bug when drag'n'dropping folders in the sandbox  Will fix it ASAP and report here

@Deltakosh To be clear, I assume this fix has nothing to do with the performance issues I and others are seeing with 3.2 correct? (because performance issues are happening outside of sandbox).

[thrice]

19 hours ago, MackeyK24 said:

Hey @Deltakosh im in the same boat and i dont know how to really interpret the profiler to be able to pin point what the problem is. All i can say for sure is, i had the space shooter demo going (you saw it). That demo is using 3.1 alpha. That demo is use Cannon Physics for EVERYTHING... all the player, enymnet and laser bolt movements, all the the collision detection, basically the whole game. But when i updated to 3.1 beta (or greater). All the stuff using cannon physics is just dog slow. Like my asteroids falling is just WAY slow, collision are not happening (some are, but most not). It just really funky... I will put up another demo of the same game but using the latest babylonjs... Maybe you can tell with the profiler.

It does not give any errors is just kinda funky...

Here is the first Space Shooter 3.1 Alpha works great...

Now here is same game with updated BabylonJS: Space Shooter 3.2 Alpha

Please see if you can tell what is going on... Or anyone else who might have some insight

 

Is it possible to easily disable the physics engine in your project, and update to 3.2 just to rule that out as the culprit? Because I am seeing the behavior without any physics enabled on my scenes (and not sure if the sponza demo is using physics but I would imagine not).

^ (unless as I was theorizing earlier, somehow physics is getting auto enabled or something, since this all did start happening as soon as cannon.js was included as part of the bundle. I doubt that is it based on profiles and what not but the timing of cannon.js all of the sudden being packaged with babylon / performance issues arising, does seem suspicious.)