Strings behind the scene

What’s really happening behind the scenes with the strings you create?

I will try to show what’s happening and what to think of when generating a string. And to visualize it I will use log messages.

Often I see log messages where the whole message is created as it should be logged. This is a pretty bad idea in performance perspective, since it always have to generate the string no matter what, even if the log message is discarded. So I will show you what the Java compiler actually does with the string messages you create.

But this will not be another performance comparison blog post. I will just try to show what’s happening behind the scenes with some byte code, then you will have to make your own assumptions. Of course I will tell you my point of view 🙂

Let’s start with a more or less common examples.

The interesting part of the byte code is what’s happening within the loop:

It creates a new StringBuilder in each iteration and appends the logStr (ALOAD 2) and then appends the variable value. ASTORE 2 simply means that it stores the toString value to logStr. You don’t have to understand the byte code, the important thing is that it creates a StringBuilder in each iteration and makes an extra append-call, simply unnecessary and might be a performance issue in larger systems.

Let’s take another example with the string + operator.

This is a very common approach of creating log messages. The compiler simply creates a StringBuilder and each plus-operator is basically translated to an append-call.

Pretty neat, huh? The Java compiler is not that stupid after all. You might have heard someone say “don’t use + when working with strings“, that was true, back in Java 1.4, but now the compiler is a bit smarter 🙂

So lets see what happens if we use a StringBuilder directly, instead.

And the byte code:

Not much to say. Almost identical to logWithConcat. Just some more line number changes.

So lets look at something else, a log message using parameters instead.

So this is compiled to creation of an array and then just a method invocation. In other words, this is probably the fastest solution in my examples.

So what do I want to tell you with this? As you can see the Java compiler always uses the StringBuilder (stop using StringBuffer!!) when it creates the strings for you.

Of course it’s not totally free to generate the string with a StringBuilder. That’s why all (good) logging frameworks also has the solution with the string format pattern. That will not produce anything else than one method call and possibly an array creation, but that’s pretty fast. Some frameworks also defines methods that actually takes two arguments instead of an array to speed up those logging messages that only takes two arguments, then no array is created. Some might even have more than that.

And then, of course, some logging frameworks has been adding support for Java 8 suppliers and lambdas, that is probably the sweetest solution 🙂

Well, you get the point 🙂 Happy string creation.

You may as well see this post at http://teknikbloggenhrm.blogspot.se/2016/04/string-behind-scenes.html

Observables with SQLiteOpenHelper

Lets look at some code on how to use Observables with SQLiteOpenHelper.

I suppose you know how to work with SQLite in Android. Otherwise, take a look at http://developer.android.com/training/basics/data-storage/databases.html

So lets assume we got this class Database with whatever needed to create any tables needed.

The code below shows how to make a query and an insert. As you can see the query and insert is just like always, the only different is the creation of an observable and notification to the subscriber when query/insert is done.

So those methods can then be used asynchronous and the subscription is notified when done. The subscribeOn is taking a scheduler where the above methods will be executed, and observeOn where the subscription is executed (the code in .subscribe). AndroidSchedulers.mainThread() must be used if updating the UI.

Now I will show you a pretty neat feature that I often use when chaining observables, the flatMap. The code below writes the name to the database, the returned id is then passed to the get-method.

So that’s a way of using observables with Android and SQLlite.

Dependencies used:
me.tatarka:gradle-retrolambda:3.2.3
io.reactivex:rxandroid:1.1.0