At the moment in jme3 java.util is used to the max and that slows the performance somewhat considerably, why not use trove for primitive types and javolution to handle lists and maps. [Note: Alot of loops even use get() method and not using a default iterator operation in a loop]
I personally had to use javolution since some of my requirements depended on concurrent and fast actions, and the current ArrayLists in render manager proved disliking since i was getting concurrent exceptions and the current list-like handling of node/geometry/etc-spatials has a really bad effect on fps. I dont have a uber pc to run jme3 on with more then 60 FPS(filters + scene + physics) but making a few slight changes proved that more fpses can be extracted with just some simple replacements.
So, anyone has any arguments bout this subject?
Because by using the standard classes we gain all improvements made there. Its the same reason we dont use scala or log4j
yeah tho, those libs improve as well, + that java.util is still and most probably will ever be as is right now, slow. And also i do use log4j on my jme3 project >.>
Yeah, you can use all these libs no problem but we dont force you to by using the standard libraries. Also the standard lbraries are compatible to all third party libs while most third party libs are not. I also dont exactly know what you mean by slow, the HashMap implementations etc. are as fast or slow as a hashmap normally is, same for LinkedLists etc etc
I see your point now, and for the slow part, javolution dose offer a slight difference over hahsmap, also javolution’s fastmap is not an implementation of hashmap.
Well please don’t get this wrong, but please give some hard facts why they are faster. Before that noone will even consider what you posted for real.
If i have the time, i can prove it. Tho anyway theres no real reason of using it, as normen stated.
I have been making sure jME3 is efficient while I was developing it. Let me assure you that any slowdowns you experience is almost entirely GPU related and not with jME3’s use of collections. Micro optimizations like those are quite useless when you could gain much higher performance by using geometry batching, texture atlases, or spatial partitioning algorithms.