Question

I’m having to think hard about optimisation in an Android app for the first time.

I have searched, but the more I search, the more confused I get. Does anyone know of good documentation to describe how each of the Java and JVM components optimise WRT JAVAC bytecode and Dalvik bytecode? Is most of it done by Dalvik and is therefore “black boxed” away from me? Is it worth looking at?

Some trivial examples.

SharedPreferences settings = getSharedPreferences(MY_PREFERENCES, MODE_PRIVATE);
SharedPreferences.Editor prefEditor = settings.edit();
prefeditor.putString("FOO", "BAR"); 
prefEditor.commit();

vs

getSharedPreferences(MY_PREFERENCES, MODE_PRIVATE).settings.edit().putString("FOO","BAR").commit();

or

int a, b, c;

a = 2;
b = 3;

c = sum(a,b);

int sum(int x, int y){return x + y;}

vs

c = a + b;

My reason for asking is to understand the tradeoff between readability and maintainability and performance. I know that the standard answer is “measure it” but I am trying to move beyond that and think in advance where I can gain performance rather than have to go back into complex code and refactor based on metrics. I will of course measure and profile anyway but my question is about understanding.

I am open minded enough to accept “don’t even go there, write, measure and be damned”!

Thanks for any insights.

Answer 1

For an android application, your code goes through 2 compilation/optimization passes. The first is performed by javac, when you compile the java code to java bytecode. The 2nd is performed by dx, when you translate the java bytecode to dalvik bytecode.

I’m not familiar with any documentation that describes the optimizations performed by either. But both are open source (via openjdk, for javac), so you could theoretically examine both to get a feel for what optimizations they do.

However, your examples really have nothing to do with compiler level optimizations. I don’t think knowing how, e.g., dx optimally allocates registers will help you to understand how to write performant java code.

For the two sets of examples that you mention, I would suggest trying 2 things on both sets of examples.

---

1. Disassemble

The first thing would be to disassemble the dalvik bytecode, and take a look at any differences. Simply counting the instructions won’t necessarily tell you anything, but in some cases it is clear that one is faster than the other.

For example, in your first set of examples, the bytecode for both snippets is nearly identical, with the exception that the 2nd snippet contains an additional instruction. So the first snippet is clearly more performant, although it would be an extremely minor performance difference.

invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences$Editor;->putString(Ljava/lang/String;Ljava/lang/String;)Landroid/content/SharedPreferences$Editor;
invoke-interface {v0}, Landroid/content/SharedPreferences$Editor;->commit()Z

vs.

invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences$Editor;->putString(Ljava/lang/String;Ljava/lang/String;)Landroid/content/SharedPreferences$Editor;
move-result-object v0
invoke-interface {v0}, Landroid/content/SharedPreferences$Editor;->commit()Z

This extra instruction makes sense, if you take a close look at the two java snippets. In the first, the return value of putString is ignored, and commit is called on the same value that you called putString on. While in the 2nd snippet, clone() is called on the value returned by putString(), which requires an extra operation in the dalvik bytecode to save off the return value. Namely, the extra move-result-object instruction that you see there.

We, as the programmers, know that the return value of the putString method is the same object that is is being called on. However, the compiler can’t know or assume this.

---

2. Measure

The second thing you can do is, as you mention, to actually profile them and measure the performance. After a while, you should start to get a feel for the types of things you can do to improve performance.