jirr and irrlicht
jirr and irrlicht
Is there any performance difference between irrlicht with C++ and jirr? Is pass by value in java makes things much slower?
Re: jirr and irrlicht
No. I get nearly the same FPS rate with Jirr with the Techdemo for example.
But the communitaction is slow. If you need to pass much data to Irrlicht or back to Jirr, it can get very slow (e.g. never create new Irrlicht objects in each frame, try to reuse them as often as possible! Extend for example recti by a set(...)-method, so you can use it more often!), because the garbage collector seems to need extremly much time to clear up Irrlicht objects.
But the communitaction is slow. If you need to pass much data to Irrlicht or back to Jirr, it can get very slow (e.g. never create new Irrlicht objects in each frame, try to reuse them as often as possible! Extend for example recti by a set(...)-method, so you can use it more often!), because the garbage collector seems to need extremly much time to clear up Irrlicht objects.
Andi is totally right - as usual 
Running jirr may reach the full c++ numbers (at least by 90 to 99,99% depending on your tasks) - but due to garbage collection this may decrease. Just think about a framerate of 1000 frames per second and intensive memory usage per frame. The gc will do a lot aof work ...
Also playing music (mp3) in pure java did reduce the frame rates. That's why there is also a java binding for irrklang in the latest version of jirr.
Last but not least with the upcoming jirr 1.3 there will be some overhead when it comes to textures being created in 100% java (not read from disk). Exchanging arrays between java and c++ is always more expensive than changing native ones. But do not expect it to be too slow to be used
Running jirr may reach the full c++ numbers (at least by 90 to 99,99% depending on your tasks) - but due to garbage collection this may decrease. Just think about a framerate of 1000 frames per second and intensive memory usage per frame. The gc will do a lot aof work ...
Also playing music (mp3) in pure java did reduce the frame rates. That's why there is also a java binding for irrklang in the latest version of jirr.
Last but not least with the upcoming jirr 1.3 there will be some overhead when it comes to textures being created in 100% java (not read from disk). Exchanging arrays between java and c++ is always more expensive than changing native ones. But do not expect it to be too slow to be used
The slowdown is most likely because of the finalizers like this one:
The Java GC is notoriously slow for classes that use finalizers and even then it does not guarantee when those finalizers will be run... if ever!
Read this IBM article about Java finalizers: http://www-128.ibm.com/developerworks/j ... 0319a.html
(it has links to more interesting info about GC)
You might try to see what happens with the performance after you remove all the finalizers from the code. Yes I understand that this means that you should be very carefull to always delete your objects to prevent memory leaks but depending on the speed-gain it might be a price you are willing to pay.
Code: Select all
protected void finalize() {
delete();
}
Read this IBM article about Java finalizers: http://www-128.ibm.com/developerworks/j ... 0319a.html
(it has links to more interesting info about GC)
You might try to see what happens with the performance after you remove all the finalizers from the code. Yes I understand that this means that you should be very carefull to always delete your objects to prevent memory leaks but depending on the speed-gain it might be a price you are willing to pay.
And about the passing of large amounts of data: that's what NIO buffers are for. Especially if all you are passing are things like vertices, indices and texture data you should consider switching to those buffers, the speed increase is considerable. The downside of course is that you won't be able to keep the API 100% similar to the C++ version.