Does Log.i() affect performance on Android applications?

Question

I'm an old school developer (OK, I'm 20, I'm not old school, I just like printing it out instead of using the step-by-step debugger :P ) and I have a lot of Log.i() calls in an Android application. I was wondering if it would have an impact on the performance of the app?

I know I should use a step-by-step debugger, it's just that debugging multiple threads can be a little cumbersome.

Thanks for your help!

Answer 1

I don't think Log will affect to application performance, because when release app, you turn off it in Android Manifest by setting debuggable:

<application android:icon="@drawable/icon" 
        android:label="@string/app_name"
        android:debuggable="false">

Answer 2

I'm still looking into Android coding myself but I from what I've seen so far I would assume that the Android logging suffers from the same issues that most Java logging frameworks suffer from (The notable exception being SLF4J), namely:

• Logging does effect performance because:
  1. It means extra method calls. (Not an issue for 99% of apps).
  2. It often means String assembly work (Big impact)
  3. It engages extra IO (Big impact)

Developers typically deal with this by adding guard blocks

if (log.isDebugEnabled()) {
   log.debug("...");
}

I think the Android SDK can do this as well. it covers off #2 and #3, but still leaves your release code containing unused logging code. assuming of course that you never want to enable debug logging in a release situation.

SFL4J BTW, doesn't require guard blocks because it used C like method calls which delay String assembly until it's actually required. Unfortunately it appears that Android has not gone down this path. iOS doesn't have this problem either because it has a pre-compiler. Something that I often wish Java had kept.

Anyway, I would not advocate removing logging in favour of the debugger. IMHO they server two different purposes. Logging I find very useful (if done properly) in understanding the flow of an application. I've often found problems by looking through logs that I would not have found in the debugger. Ie. unnecessary code execution across multiple classes (especially in UI classes), odd data issues that don't lead to actually bugs, etc. In these situations using the debugger would be like trying to lay concrete with a spoon. Debuggers on the other hand are perfect for analysing the fine details of an issue highlighted by the logging.

So in my code I tend to have a fair amount of logging which is designed to tell me what the application is doing, in an English like manner so I can read it easily and understand what is happening. But I'm fairly strict about keeping the levels as low as possible. Ie. don't log stuff at the info level unless it's something you want to see even in release mode. I've found a lot of developers tend to break this.

UPDATE: Just read Remove all debug logging calls before publishing: are there tools to do this? which talks about how you can use ProGuard to strip logging from release code. Great idea, means you can not bother with guard blocks on logging and put as much in as you like, yet still be assured that your release code will be fast.