Catastrophic performance vs. JRE 1.6 on desktop computer!!!

Common bugs/problems with the Android SDK the Emulator and the ADT-Plugin.

Catastrophic performance vs. JRE 1.6 on desktop computer!!!

Postby Steel » Tue Feb 12, 2008 2:40 pm

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 :o
Steel
Developer
Developer
 
Posts: 48
Joined: Fri Dec 28, 2007 1:11 pm
Location: Herning, Denmark

Top

Postby plusminus » Tue Feb 12, 2008 3:15 pm

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
Image
Image | Android Development Community / Tutorials
User avatar
plusminus
Site Admin
Site Admin
 
Posts: 2688
Joined: Wed Nov 14, 2007 8:37 pm
Location: Schriesheim, Germany

Postby Steel » Tue Feb 12, 2008 6:41 pm

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?
Steel
Developer
Developer
 
Posts: 48
Joined: Fri Dec 28, 2007 1:11 pm
Location: Herning, Denmark

Postby plusminus » Tue Feb 12, 2008 6:57 pm

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


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

Regards,
plusminus
Image
Image | Android Development Community / Tutorials
User avatar
plusminus
Site Admin
Site Admin
 
Posts: 2688
Joined: Wed Nov 14, 2007 8:37 pm
Location: Schriesheim, Germany

Postby plusminus » Tue Feb 12, 2008 8:10 pm

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

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

Regards,
plusminus
Image
Image | Android Development Community / Tutorials
User avatar
plusminus
Site Admin
Site Admin
 
Posts: 2688
Joined: Wed Nov 14, 2007 8:37 pm
Location: Schriesheim, Germany

Postby Steel » Mon Mar 10, 2008 1:59 pm

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
Steel
Developer
Developer
 
Posts: 48
Joined: Fri Dec 28, 2007 1:11 pm
Location: Herning, Denmark

Top

Postby plusminus » Mon Mar 10, 2008 10:00 pm

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
Image
Image | Android Development Community / Tutorials
User avatar
plusminus
Site Admin
Site Admin
 
Posts: 2688
Joined: Wed Nov 14, 2007 8:37 pm
Location: Schriesheim, Germany

Postby Steel » Mon Mar 10, 2008 10:14 pm

That might be true, plusminus, but for the Android Developer Challenge, every entry will be judged on it's usability & performance on the emulator.
Steel
Developer
Developer
 
Posts: 48
Joined: Fri Dec 28, 2007 1:11 pm
Location: Herning, Denmark

Postby plusminus » Mon Mar 10, 2008 10:23 pm

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
Image
Image | Android Development Community / Tutorials
User avatar
plusminus
Site Admin
Site Admin
 
Posts: 2688
Joined: Wed Nov 14, 2007 8:37 pm
Location: Schriesheim, Germany

Top

Return to SDK/ADT/Emulator Problems

Who is online

Users browsing this forum: No registered users and 8 guests