Performance Results for Android Emulators - with and without Intel HAXM

 

Welcome to my blog about Android Emulator performance. I started comparing the performance of the generic emulator in Eclipse and the x86 Emulator that utilizes the Intel® Hardware Accelerated Execution Manager (Intel HAXM) and was quite surprised at the difference in performance. So here is the blog!


Description:

I recently started learning about Android App Development and in the process I have been going through the training tutorials on developer.android.com. The app that I used for the tests below is based on the "MyFirstApp" offered in the training. I made it as far as creating the two intents so there isn't much processing it has to do (it is probably the most basic app that exists.) The reason why I shifted to emulator performance was I got really tired of waiting for the emulator to load so that I could test my app.

Test System Configuration:

  • Windows 7
  • HP Elitebook 2560p
  • Processor has Intel(r) VT-x and it is enabled in the Bios
  • Beacon Mountain (takes care of installing all components - Eclipse, Intel(r) Hardware Accelerated Execution Manager (Intel Haxm), Android ADT, Android, SDK, etc. (Note - Intel VT-x is required to install Beacon Mountain.)

Disclaimer: The performance results below are based on my system that has all software associated with a Corporate IT Build installed and running. It was not prepped for "Performance testing." The results below will vary according to specific system configuration.

The Basic Emulators:

In my installation of Eclipse, I have just the two basic emulators: Nexus_7_arm and the Nexus_7_x86.

Open the Android SDK Manager to see which emulators are available:

The available images come with the specific Android API version.

For Android 4.4, you can install an ARM System Image and an Intel x86 Atom System Image

Intel HAXM is also included. Go to the "Extras" portion of the Andorid SDK Manager and make sure it is installed.

Support for Intel HAXM was introduced in Release 17 of the Android ADT and it works with Intel x86 images going back to API Level 10.

The tests run below were against both emulators as well as my Note 2 "Phablet."

This window comes up when you run your app. If your device is in "Developer Mode" and is connected via USB cable, it will show up as an option for the "running device." Note that the Google USB driver did not work for the Note 2 - I had to get it from the Samsung website.

The results:

The chart shows why I started looking into Intel HAXM. I got really tired of waiting for "MyFirstApp" which is really tiny and insignificant to load and run.

While 7 seconds for uploading directly to my Note 2 wins the race, waiting 43 seconds is much more desirable than waiting a total of 2 and a half minutes.

Since the Note 2 does not need to "boot" every time it runs, I decided to see how much time the emulators were spending just loading the OS.

The Nexus_7_arm emulator takes 2.2 times longer to load. Note that at 40 seconds the x86 emulator is almost done.

The Note 2 time is 0 since it is not loading the OS everytime the App is uploaded.

Then I decided to see how much time each took to upload, install and run my app.

The ARM emulator took 23 times longer to upload and install than the x86 emulator (over a minute vs 3 seconds for the x86 emulator.) And the x86 emulator was faster than my Note 2 by 1 second. I was not surprised by that.

Summary

While you still have to wait for the OS to load when using the Intel x86 emulator with Intel HAXM enabled, the total run time is much faster than waiting for the generic ARM emulator (3.65X more time overall to run.) Since the biggest difference in time was in uploading and installing the app, I would imagine that if my app was actually complex the overall performance difference would be far greater.

The really neat thing about this emulator is: Even if your app is targeted for ARM devices, the Intel HAXM enabled emulator can be used for testing. This can save a lot of time.


See Gael's Blog Author Page

For more complete information about compiler optimizations, see our Optimization Notice.