Chapter 17: Start profiling your app's performance

I recently attended a seminar where I was let to know that it is better practice to base your design decision on data rather than opinion. This came of course as a shock to me - not the fact that data is​ more reliable than opinion in itself, but the thing that it is recognized as a best practice. My personal experience is that opinion overrides facts. Every time. But let's not open up that can of worms for now ;-)

As the previous chapter gave us some kind of low-water mark, this is a golden opportunity to start using the Profiling functions in Eclipse/Android SDK, so we can measure what improvements we get with a re-design of the rotation mechanism.


First - switch view in Eclipse with: Window -> Open Perspective -> DDMS. (You get back to the standard view with Window -> Open Perspective -> Java).

As I'm using Android 2.1, I must also allow my app write access to the SD Card, by adding:

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

to my manifest file.

Redeploy the app (ctrl-F11), and wait for it to start up and click "Play" when the main menu shows.

Select your app's process and click Start Method Profiling in the toolbar:

 Let the asteroid sweep (or perhaps "stumble" in this case) a few times and then click Stop Method Profiling.

Now the profiling data will be pulled from the device into Eclipse and you will see everything you need.


First off is the timeline, which gives a very clear visualization of the periodic GCs that my excessive object creations causes. It is quite bad:

Then, let's expand the thread tree and find out what the CPU is busy with:

Here we see that our GameEngine's draw-method takes 70.9% av all CPU cycles available, so of course we focus on that and expand it's Children tree.

There it is obvious that GfxObject.draw is next point of focus with it's 94.4%.

We continue to drill our way down via GfxObject.rotate to the two calls to Bitmap.createBitmap.

0.709 * 0.944 * 0.956 * (0.702 + 0.250) = 0.61

My poor device is spending 61% of it's time creating bitmaps!


Normally, I focus on the top three bottlenecks in my development/optimization/tuning activities, but in this case we have enough material to just go ahead and stop creating bitmaps each frame.


(Reference material: