thrice

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

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]}

 

Share this post


Link to post
Share on other sites

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. 

 

5a20e3715059b_Screenshot2017-11-3006_29_12.thumb.png.12ac11e9c81451e4b7af3e3c471dd9ba.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ?

5a383eef0541e_Screenshot2017-12-1815_12_57.thumb.png.461455587429ac6dedf659189896f4f3.png

5a383efa2a1f5_Screenshot2017-12-1815_13_21.thumb.png.ea9f91c95193f042542a7ec49b7df2d5.png

5a383f082ed6d_Screenshot2017-12-1815_14_03.thumb.png.c1176a05f0baeb4bcb29859a83808289.png

5a383f1d4e667_Screenshot2017-12-1815_15_34.thumb.png.fce2407f328f2ace6d2fdc0451d5c84f.png5a383f12cb76d_Screenshot2017-12-1815_14_36.thumb.png.d986d411adc67a1d318575c0211c9198.png

Share this post


Link to post
Share on other sites

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 :)

 

Share this post


Link to post
Share on other sites

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/

5a38dfb7d7c86_Capturedecran2017-12-19a10_36_52.png.01534e3edc53b2b2bcb28f37f247e2a4.png

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):

5a38e3999c980_Capturedecran2017-12-19a10_58_04.png.cc1ac3be6141280266a2ef9ed8dd401e.png

 

• Babylon sandbox (without postprocesses):

5a38e39948b60_Capturedecran2017-12-19a11_00_07.png.70aa69a5f7c96a58bc65914b581f89fd.png

 

@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 ) :

5a38f24fa0fac_Capturedecran2017-12-19a11_59_20.thumb.png.a752ccdfa698407691620c90a359d875.png

 

• Babylon sandbox (without postprocesses):

5a38f26f5de7e_Capturedecran2017-12-19a11_59_30.thumb.png.8328c00e4aaac832384a8781c3a477e3.png

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 )

 

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.