Android Performance Advice

[jp.lorandi]

Is this official? much of this advice is true for C++ but was not true for Java.

Android doesn't run Java. It compiles from Java (or a Java-like language) into it's own kind of bytecode. Also, many of these optimizations aren't necessarily run-time ones... Avoid Internal Getters/Setters or Cache Field Lookups should easily be implemented in the compiler at a marginal code size cost.

I work with embedded systems a lot (casino games mostly), and while our hardware constraints in terms of RAM & CPU power aren't as stringent as with phones, I can tell you that something like the Avoid Float section means you cannot in practice use ardor3d in something like android. The architecture of ardor3d will prevent any practical success. A branch would be my choice.

[renanse]

As I said before in this thread, I believe you'd have more success with a purpose built 3d library. However, back in my jME days and with a very early android sdk I was able to get the jME box example running on their emulator without a whole lot of problems (and without replacing all the floats, etc.) *shrug*

[jeffpk]

Is this official? much of this advice is true for C++ but was not true for Java.

Android doesn't run Java. It compiles from Java (or a Java-like language) into it's own kind of bytecode. Also, many of these optimizations aren't necessarily run-time ones... Avoid Internal Getters/Setters or Cache Field Lookups should easily be implemented in the compiler at a marginal code size cost.

Okay, so your point is it ahs neither good run-time optimization NOR good compile time optimization.

Bleh.

(Btw: Hostpot's run-tiem optimizations make such compile time optimizations unnecessary. It covers those
points AND the rest.)

I work with embedded systems a lot (casino games mostly), and while our hardware constraints in terms of RAM & CPU power aren't as stringent as with phones, I can tell you that something like the Avoid Float section means you cannot in practice use ardor3d in something like android. The architecture of ardor3d will prevent any practical success. A branch would be my choice.

My choice would be screw android until they have a real modern VM. It was fine that they chose to make their own VM but then make it as good as existing technologies (eg Java, .NET)

[jp.lorandi]

Okay, so your point is it ahs neither good run-time optimization NOR good compile time optimization.

Bleh.

(Btw: Hostpot's run-tiem optimizations make such compile time optimizations unnecessary. It covers those
points AND the rest.)

Yeah. And there's no hotspot. There's a JIT compiler there, and it's not on par with the JIT compiler of the latest Java VM's (basic GC implementations).

My choice would be screw android until they have a real modern VM. It was fine that they chose to make their own VM but then make it as good as existing technologies (eg Java, .NET)

Pretty much my choice as well, at least in terms of certain basic stuff (even without these restrictions, ardor would be extremely slow even for 2D orthogonal perspective apps). The only "platform" where you may conceivably code games using a 3D API that's viable enough both tecnologically and financially is the iPhone. There are phones that are hardware accelerated, but the capabilities they have vary way too much between one vendor/model and the next to make it worth your while, in terms of releasing a mainstream game. It's a pity but also it's a consequence of trying to have a one-size fits all gadget -- they wind up not doing anything particularily well, IMO.

[jp.lorandi]

As I said before in this thread, I believe you'd have more success with a purpose built 3d library. However, back in my jME days and with a very early android sdk I was able to get the jME box example running on their emulator without a whole lot of problems (and without replacing all the floats, etc.) *shrug*

The emulator is solely functional. Non functional issues, like CPU power, Memory, Interrupt Handling (that CPU processes data of the radio(s) for cell, 3G, bluetooth) are left out. Pretty much the same as the J2ME emulator, at least right now.

This set of suggestions is geared towards any application -- they weren't even thinking specifically of your 5-15 fps 2D game, and nowhere near your very low poly, low mesh count 3D game, so it's not a viable alternative just yet. That said, I belive Android is going places, and should the folks at Google decide their OpenGL stack and VM are worth spending some time on, we're going to have a platform that's on par with the iPhone and even more ubiquitous.

The important issue on this field is what Sun will do about J2ME and their approach/attitude to embedded systems in general. They have opened up their Field of Use restrictions except on cell phones last Dec 5. Eventually, if all field restrictions are lifted, you may have a Kaffe or Harmony JVM running on cell phones with the Java brand as well as a Sun produced one.

For the short term, I'll stick to Ardor3D and the PC platform.