It sounds like the sort of thing any C programmer went through 5-10years ago when they first encountered Java. Java is what it is and I wouldn't generalise the comments beyond this: If you're thinking of copy'n'pasting your Objective-C iPhone into Eclipse and changing some method calls, don't. Different devices and different languages with different capabilities and performance profiles require different thinking and different approaches. In short, they're different.
There is no JIT-compiler on Dalvik, and its garbage collector is a very slow mark-sweep. Both are known deficiencies being addressed by the Android team.
I've been working with SISC Scheme on Android, where it is truly slow. At the moment it is little more than a toy, a Schemely palmtop calculator.
I don't think you can infer much from this article. It was a half-assed attempt to cut and paste a program from one platform and language to another. He uses a horror movie motif throughout the essay, but the right horror story for his development style is "Frankenstein."
tl;dr: Java's not all that great for writing the typical gory OpenGL code you need for great performance, while Objective-C's (C's) pretty good at it; also, the iPhone dev environment is pretty good, compared to Android's.
You have to plan from the beginning to abstract away the system-specific stuff.
Java: I only wrap what I need with JNI and use C for the rest. Anybody would get burned out trying to cut-paste a huge Objective C program into Java.
Debugging: good old asserts and printfs are your friend. Last I checked asserts weren't working out-of-the-box on Android, so you may need to roll your own log/assert macros.
Profiling: it's not supported very well on the NDK, so take 15 minutes to add timestamps to critical parts of the code and printf.
OpenGL: again, target C for the bulk of your code and vertex buffer objects and interleaved arrays work great. No need for ByteBuffer madness.
Fixed point: ARM chips are not going away anytime soon. Converting your data to fixed point before uploading it to the GPU is a simple problem compared to getting your fancy website to render properly in IE6 or your pretty desktop game to not choke on Intel Accelerated Graphics. Do microbenchmarks once at runtime or test lots of different devices to see what kind of data works best on the host device.
Good thing is you only have to do these things once, ever. Once you have your build system setup and all your happy interface libraries running you can do the same things for all your Android+iPhone projects.
As someone with C, C++, and Java experience, but no Objective C, I started reading this article with interest. But it lost a lot of credibility with me when he started complaining about Java strings not being null-terminated. Also it sounded like he had coded his app specifically for iPhone hardware capabilities and not tried much more than a naive port.
It would have helped if he had broken his rant out into "things that I wasn't used to" and "things which are broken". As it stands it seems he just wants his Nexus One to be an iPhone. When he already has an iPhone.
8 comments
[ 2.6 ms ] story [ 24.2 ms ] threadIs Java on Android _really_ slow? Or is it the porting of objective C to Java?
I'd really like to know. I have an interest in developing for the Android.
I've been working with SISC Scheme on Android, where it is truly slow. At the moment it is little more than a toy, a Schemely palmtop calculator.
Java: I only wrap what I need with JNI and use C for the rest. Anybody would get burned out trying to cut-paste a huge Objective C program into Java.
Debugging: good old asserts and printfs are your friend. Last I checked asserts weren't working out-of-the-box on Android, so you may need to roll your own log/assert macros.
Profiling: it's not supported very well on the NDK, so take 15 minutes to add timestamps to critical parts of the code and printf.
OpenGL: again, target C for the bulk of your code and vertex buffer objects and interleaved arrays work great. No need for ByteBuffer madness.
Fixed point: ARM chips are not going away anytime soon. Converting your data to fixed point before uploading it to the GPU is a simple problem compared to getting your fancy website to render properly in IE6 or your pretty desktop game to not choke on Intel Accelerated Graphics. Do microbenchmarks once at runtime or test lots of different devices to see what kind of data works best on the host device.
Good thing is you only have to do these things once, ever. Once you have your build system setup and all your happy interface libraries running you can do the same things for all your Android+iPhone projects.
It would have helped if he had broken his rant out into "things that I wasn't used to" and "things which are broken". As it stands it seems he just wants his Nexus One to be an iPhone. When he already has an iPhone.