Hi Jack,
would you be able to share the project somehow? I really doubt it is because of the es version. We have made different changes in every minor version, and it would be great to debug the performance and see what causes the slowdown.
Thank you for your answer unfortunately I canât share my project itâs a big scene with several objects loaded async.
inspector 5.21.0 vs 5.40.0
1 Like
I am less interested in the inspector and more in the performance profiler in your browser.
I want to know what takes so long to run on each frame.
You said you are using a lot of textures - are you continuously creating and disposing them by any chance?
if you want to take a look, here is the project running in 5.40.0
1 Like
Could you also share the version relying on 5.21 so we can compare and find the culprit ?
1 Like
Is the version you shared using minified Babylon.js packages? If yes, are you able to setup a link where they would not be minified?
sure here in 5.21.0
I donât think babylon.js is minified
2 Likes
@Evgeni_Popov can you have a look ???
@Jack could you deploy a 5.40 built like the 5.21 ? so it is easier to compare for us ?
And btw Thanks a lot for the repro the diff is amazingly obvious here.
1 Like
Thereâs something which is wrong with the slow link.
When comparing the call stack for some gfx related calls in Spector, I get this in the slow link:
And this in the fast link:
It makes me think that there is an additional processing on the js code before publishing in the slow link: are you able to remove this processing so that we have a fair comparison between both cases?
Hi, Itâs strange because there is no code added between the two builds. Here are two others where I am certain the only thing that changes is the version of Babylon.js with 5.21.0 and 5.40.0
If I can help in any way, donât hesitate to ask.
I think itâs your packager which decided to use another minification algorithm for 5.40, probably because it is bigger than 5.22, to better compress it. But by doing so it seems it adds a number of indirections to access objects, which is slow.
Can you remove / disable the minification altogether? Or fix the algorithm used by the minificator?
As an example, functions are declared inside an object in the slow link:
}, {
key: "drawUnIndexed",
value: function(e, t, i, n) {
this.drawArraysType(e ? 0 : 1, t, i, n)
}
}, {
key: "drawElementsType",
value: function(e, t, i, n) {
this.applyStates(),
this._reportDrawCall();
var r = this._drawMode(e)
, a = this._uintIndicesCurrentlySet ? this._gl.UNSIGNED_INT : this._gl.UNSIGNED_SHORT
, s = this._uintIndicesCurrentlySet ? 4 : 2;
n ? this._gl.drawElementsInstanced(r, i, a, t * s, n) : this._gl.drawElements(r, i, a, t * s)
}
}, {
key: "drawArraysType",
value: function(e, t, i, n) {
this.applyStates(),
this._reportDrawCall();
var r = this._drawMode(e);
n ? this._gl.drawArraysInstanced(r, t, i, n) : this._gl.drawArrays(r, t, i)
}
}, {
whereas they are declared on the prototype as expected in the fast link:
e.prototype.drawUnIndexed = function(e, t, i, n) {
this.drawArraysType(e ? 0 : 1, t, i, n)
}
,
e.prototype.drawElementsType = function(e, t, i, n) {
this.applyStates(),
this._reportDrawCall();
var r = this._drawMode(e)
, o = this._uintIndicesCurrentlySet ? this._gl.UNSIGNED_INT : this._gl.UNSIGNED_SHORT
, a = this._uintIndicesCurrentlySet ? 4 : 2;
n ? this._gl.drawElementsInstanced(r, i, o, t * a, n) : this._gl.drawElements(r, i, o, t * a)
}
,
e.prototype.drawArraysType = function(e, t, i, n) {
this.applyStates(),
this._reportDrawCall();
var r = this._drawMode(e);
n ? this._gl.drawArraysInstanced(r, t, i, n) : this._gl.drawArrays(r, t, i)
}
1 Like
this feels like the wrong way to minify classes, you are totally right. The difference here is that we used to move the classes to es5-style prototypes, and now we deliver classes and let you decide how to minify it.
I have so many questions @Jack 
- What es version are you targeting here?
- what packer are you using?
- And what minifier are you using? (default from the packer? different one?)
- How does your browserlist look like? is it being taken into account?
Our playground is using minified code (with sourcemaps) and doesnât have all of those âvalueâ access, which of course slow down the entire process.
2 Likes
After a bit of research - you are probably using babel-minify. Maybe an old version or incorrectly configured? If you are - babel-minify is in beta and I would not recommend using it for production. Terser and uglify are both a more viable option in that case.
1 Like
I am targeting the ES6 version, the project is based on CRA that has not been ejected with the default webpack parameters visible here.
Here is my browserlist configuration:
[
">0.2%",
"not dead",
"not ie <= 11",
"not op_mini all"
]
Webpack uses terser per default, which is the minifier we are using as well. There must be an extra step that triggers a different minifier. It is really just a react app with the default configuration? If it is I can try creating a react app and check the build process. but it feels weird, because we are not doing anything special - those are classes, and they are being minified in a very weird way for some reasonâŚ
2 Likes
Yes, these are the default settings for CRA.
I am updating all of my packages to the latest versions.
But it will take some time, I have a lot of breaking changesâŚ
iâll create a react app later and try it out. havenât heard of this issue before TBH, but if this is the case with CRA we need to do our best to resolve this
1 Like
but if this is the case with CRA
Hasnât that been the common denominator on this thread?
There must be an extra step that triggers a different minifier.
I think youâre onto something.