Closed aW4KeNiNG closed 8 years ago
Hi, yes, perf has dropped down because of latest changes in BJS materials because of which I had to go back to the initial implementation in BHx which uses Map() - and its very slow. In the mean time I've done some work to speed it up (again, previous way of material handling in BHx was pretty fast) so it should be faster but there are a lot of changes right now all over the place... Don't know if I can push only materials changes and keep master branch stable...
I've just pushed updated materials, hopefully it work... This version should be faster (but not as fast as the previous fast one I guess...) There were some drastic changes in BJS materials code and this is probably the fastest implementation of materials in BHx after those changes. Try it out and let me know if its any better.
I tested it before (1 hour ago) not knowing that BHx was updated (installed a new Windows 10 and fresh haxe install) and I noticed that it's much faster than before. I was able to show 3000 boxes-instances (all visible on screen at the same time) in HTML5 with 58-60 FPS on my mediocre PC. In Away3D I got 44FPS with 2000 instances.
Btw there are some new errors with the new Haxe Version 3.3 (html and cpp). ;)
But cool stuff, I need to draw many boxes in my new game and that performance is more than sufficient now.
Thanks @vujadin !
The difference is huge. It is fast like before. I think that we should open an issue in BJS to adapt your solution. The performance gain is so huge to ignore it. What do you think? BJS will get speed and BHX will be easier to maintain.
Feel free to close the issue ;)
PD: You need to fix the Line 1994 in Scene. I have an error: Scene.hx:1994: lines 1994-1996 : Void should be Bool
@aW4KeNiNG @mightymarcus you probably know already but you can freeze() materials that doesn't change between frames, this will boost the perf even more.
@aW4KeNiNG before proposing bhx solution to bjs people you should make sure that the actual implementation of materials in bhx is faster then in bjs (maybe the speed comes from other things Haxe provides us like method and constructor inlining (which I heavily use in BHx)). I've never compared the two myself, would be great to see actual samples that show the diff...
Wow, i didn't know about freeze materials. Thanks :)
BTW, I have sent you via email an example with the old and new version. You can see the difference. With the "economizer plan" the difference is bigger.
@aW4KeNiNG yes, the difference is quite big. there's actually a lot of room for improvements/optimization but I don't want to move away from bjs architecture, at least not yet.
Perfect :+1:
like method and constructor inlining
Hm. I was generally interested in that and was looking in the produced JS Source-Code, and it seems that inlining in JS doesn't happen. You have to explicitly turn on inlining with @:extern inline, and often the inlining makes things worse, because it creates additional anonymous functions. We could use the haxeflag "-D analyzer", but it doesn't work very well for now.
Inlining works very well for me and makes quite a difference in perf, especially constructor inlining. I haven't seen "additional anonymous functions" in generated js code but I guess it depends how and where you use inlining. I've probably misused it in a few places in BHx while experimenting but I find it works well when inlining simple(void) methods and classes with simple constructors which are heavily used all over the place, like Vector3 class for example.
The generated source code tells me another story. I looked at the Vector3 inlined methods, and I can find just one single inlined method, the other methods that are marked as inlined are not inlined. ;)
"additional anonymous functions" looks like that
https://github.com/HaxeFoundation/haxe/issues/971
Maybe it's better with haxe 3.3 now.
I asked some time ago about that problem.
UPDATE:
forget about that, you where right. Wow. Makes a good job now. :)
var v3 = new Vector3(2, 2, 2); var v32 = v3.negate();
gets
var v3_x = 2; var v3_y = 2; var v3_z = 2; new com_babylonhx_math_Vector3(-v3_x,-v3_y,-v3_z);
COOL STUFF! :)
Hi Vujadin :)
I had a version from March. After i updated to the last git version, the performance is worst (2-3x).
My old version consumes 4-5% CPU on idle. The new version consume 18%. If i assign my PC to "economizer plan" (with a slow cpu) then the fps is much lower than the old version.
I have tried to locate the problem.
Here you can see the old version profiled:
Here the new version profiled:
The cloneTo method is executed multiple times. It is used in StandardMaterial.isReady.
Any idea?