Hi there looking at the code showed me that there are quite a bunch of the nice foreach-loops.
The problem is that every of this foreach loops instantiates an iterator, so you can imagine the bigger
the scene graph the more of this instances that will be thrown away immediately. I had the same problem
with my last android-game. On the desktop it is not a problem but the android garbage collector just hates
too much work.
So all the foreach-loops (at least inside the main-loop like updateLogicState(…)) have to be cleaned out to good old
for (int i=0;i<…;i++) {} Loops.
Just wanted to let you know.
No, google has to get their act together and make a proper JVM ^^ The JIT and GC on Android plainly suck, I slowly start to understand Oracles malaise towards Android… GC thats only in what would be the “stack” in C++ should essentially be free.
lol, yeah! Actually I was also shocked! And even though someone told me before I thought “Ahh…won’t be that hard!” Maybe we could just replace the List and Map-Classes. I had a look into javolution-classes that have “realtime” or at least faster implementation of java.util. java.lang and so on: http://javolution.org/
But I don’t know if they help with that specific problem.
If you need ti now to make money, that is probably the way to go for your build.
If not, don’t support googles bad jvm implementation by adapting the engine.
Seriously, on destop jvm’s that would actually not even be a garbage collected object anymore but a REAL stackallocation.
Theres no stack in java but cleaning the young generation should be comparably quick. Otherwise I agree completely 
You are technically both right since HotSpot will likely turn temporary instances into stack allocation.
Note to the original poster, it’s even better if you can arrange to use arrays instead of iterables since then the for( Foo : array ) syntax should not create an iterator and it will be faster than indexed list look ups anyway. That’s what I wrote SafeList for… and easy way to safely access the list’s array.
1 Like
Most of the iterations in the main loop use Paul’s SafeList BTW.
1 Like
Oh yes, the problem exists only for iterating over collections my fault. So Paul’s SafeList should indeed be the the way to go. Nevertheless it doesn’t hurt to bear that problem in mind.
To just say “don’t support google’s bad jvm” I can only ROFL :roll:
Just for info: http://developer.android.com/guide/practices/design/performance.html#foreach
This is interesting, I didn’t know about that limitation on Android 
They did provide one great pointer on that page though 
Before you start optimizing, make sure you have a problem.
1 Like
@ttrocha said:
To just say "don't support google's bad jvm" I can only ROFL :roll:
Most optimizations in the JVM have been done because users use java in a certain way: http://www.youtube.com/watch?v=uL2D3qzHtqY
If we now just let them remove improvements that have been "normal" for years and adapt to a shitty JVM or go back to C/C++ I think *thats* something to laugh about. Google sells this as a "Java OS" and it cannot run java code as fast as native code, lol? By now I can only hope they have to drop java and then give us a working cross-compiler to native so we can just do it like we will on iOS later, or finally make a proper JVM.
Cool link and cool guy! Very interesting. Actually I just wanted to mention the problem. The thing is that the situation for the android platform is this way and the dalvik-vm is very limited. Therefore I posted this topic to the android-forum. I think it is something everyone who wants to code for android should be aware of.
Yes it is but imo its important that people see this. If everybody just hides the problems nobody will react. When I read that page you linked I think “why should I use java then?”. Given those restrictions I’d rather code in C. No accessors but direct object access? In Java?? lol
@normen said:
No accessors but direct object access? In Java?? lol
Actually that's a sort of trend nowadays....I've seen some of android examples doing this...
It does not feel right to me neither because i'm a old java chimp....but...I can't find any reason why this would be bad...
I mean the public modifier is there for a reason....it makes the code lighter....
Maybe Paul could explain why it's bad (he's an older java chimp :D)
Ahem… We have the same direct access functionality in our math packages (in additional to the traditional java.access methods).
Like @nehon said… its there for a reason. It could be a case of a product manager preferring one method and imposition that
But we’re having over 10 years worth of libraries that do that by default. If they now tell us “can’t use all that stuff, too slow” then whats the point in using java? Its not about using a direct accessor per se what I find “lol”, its “disallowing” it for a java application.
Sometimes it’s good. Vector3f for example, it’s really nice to be able to access the raw values because they do not mess up anything.
Quaternion on the other hand hides its access… as it should since messing with the raw values messes up the Quaternion.
Generally, the proper design (from an old-school perspective) is to leave fields private with accessors/mutators unless what you are emulating is a C-style struct with some utility functions (like Vector3f). Otherwise, you are breaking encapsulation since you cannot enforce any kind of consistency or protection on those values.
Math packages are the most common case for public fields since they are pretty often implementing some raw extended types + util functions. Java does it for some of its classes too… the closer to math you get the more likely it is to happen. Which is why many of the shape classes do it. Though the relationship between Rectangle2D and its Double and Float subclasses is a good example of where even that can be tricky.
1 Like
@normen said:
But we're having over 10 years worth of libraries that do that by default. If they now tell us "can't use all that stuff, too slow" then whats the point in using java? Its not about using a direct accessor per se what I find "lol", its "disallowing" it for a java application.
I agree, however, waiting for them to make the move is not really a viable solution.
Also what @ttrocha mentioned can be useful for users that want to make a game with JME on android right now.
Iterating over collections with iterator or accessing class members via acessors is slow on android (or gives memory issues idk), is 'lol'..but it's a fact, and it's good to know there are workarounds.
And to the question "what's the point in using java then?" i'd say because JME is based on java, that's a friggin good reason to me :D
Hehe, yeah, I didn’t want to bash anyone but google here, definitely good information by ttrocha. I just want to underline and defend what I said here. I even had a -1 for some time on my first answer so I feel theres reason to explain further ^^ I know I am obnoxious when making a point 
1 Like
For inner loops I think it is OK to optimize those for-each loops as necessary. In fact I already did many of those optimizations myself based on memory profiling jME3.
As for Android, you have to understand that the Sun JVM probably has the best JIT ever … I don’t think many can come close to the amount of optimizations that it does, so it is wrong to assume that other implementations of Java are capable of the same caliber. Besides, just because the JVM can handle those inefficiencies doesn’t mean the speed remains the same afterwards, there’s still some overhead.
For example after I did many of my garbage generation fixes, the time it took jME3 to gain full speed (500-1000 fps) on a decent size scene was like 5 seconds, now its almost instant since the JVM doesn’t need to optimize anything, the code is already optimized.
Every “other jvm” is faster than Suns ^^