I just finished converting a Java 1.6 component to Android (android_sdk_windows_m3-rc37a)

My desktop computer contains an Intel Core 2 CPU 6400 @ 2.13GHz with 3GB RAM ... and of course the Android emulator tries to emulate the speed of actual devices somehow.

Anyway, when running on JRE 1.6 on the desktop computer, the component can scan a 640x480 pixel picture in 60-360 ms.
When running the component in the Android Emulator this task takes 71-77 seconds(!)

Can that really be?! A factor 1000 slower than a desktop computer?!

This completely renders my Android application useless ... so unless I figure out how to profile the app & optimize it, I'm out of the Android Developer Contest

Hello steel,

I see you are aware that your application is running in an emulator.
Every single instruction of the emulated device has to be simulated, as ARM-Instructions are not compatible with x86-Instructions.

You can see with :src: MoseyCode that sophisticated high-performance applications can be done with Android.

Somewhere in the SDK there ae some DOs and DON'Ts to speed up your application further. Was a list of compared times of doing things like Class-Variable-Access.

Regards,
plusminus

plusminus wrote:I see you are aware that your application is running in an emulator.
Every single instruction of the emulated device has to be simulated, as ARM-Instructions are not compatible with x86-Instructions.

Please - don't state the obvious - this is not amateur night.
I just wanted to hear from other Android developers if they had the same terrible experience with runtime speed.
I'm gonna do some manual profiling on my app tomorrow to see where the time is spent, but a list of DOs & DON'Ts would be of great help - where is it?

Hello steel,

just found it

Summary:

1. Avoid Creating Objects
2. Use Native Methods
3. Prefer Virtual Over Interface
4. Prefer Static Over Virtual
5. Avoid Internal Getters/Setters
6. Cache Field Lookups
7. Declare Constants Final
8. Use Enhanced For Loop Syntax With Caution
9. Avoid Enums
10. Use Package Scope with Inner Classes
11. Avoid Float

http://code.google.com/android/toolbox/performance.html

Regards,
plusminus

Hello again,

I found an interesting paper:
http://www.dcl.info.waseda.ac.jp/public ... niques.pdf

Native x86 vs. Qemu emulated ARM:
Instructions: 72x Slowdown
Memory: 10-15x Slowdown

So you will notice a significant speedup on an actual device.

Regards,
plusminus

Okay, finally got around to do some method tracing & check out the TraceView application.

I upgraded to android-sdk_m5-rc15_windows in the hopes that the Android development team might had optimized the emulator, but it still takes 71-73 seconds (as opposed to 60-360 ms. on JRE1.6_03 on a desktop computer)

The method which has the largest excl. % (23%) just does a lot of int multiplications, comparisons, divisions, remainder (%-operator) etc. and uses Math.abs(int), so there's really not much to optimize in the java code - it's just brute calculation power that the emulator/android runtime lacks.

I've submitted Issue 435.

Hopefully something drastic will happen, I mean, as it is now, it's a lot faster to transmit an image back to a server, scan it there, and then transmit the results back. Or ... the network is faster than the CPU ... LOL

Hello steel,

there was almost no change from m5-rc14 to m5-rc15

I would not trust performance tests on the emulator.
An emulator-developer said, that your apps should run in the emulator almost as fluent as you expect them on a real device.

Anyway I do not trust in that, as performance on different pc-setups seems to be soooo large.

Regards,
plusminus

That might be true, plusminus, but for the Android Developer Challenge, every entry will be judged on it's usability & performance on the emulator.

Yes, I recognized that the emulator runs slightly faster, when starting it from the command line, that starting it from eclipse. Probably because no debug-messages are transferred.

I think they'll test it on pretty strong machines.

Regards,
plusminus