6

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!

The WebMacheter
  • 1,776
  • 1
  • 20
  • 31

5 Answers5

7

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">
anticafe
  • 6,816
  • 9
  • 43
  • 74
  • 5
    debuggable in Manifest will effect Log.d statements, but Log.i, Log.e would still be there and it would effect the performance of the app if these are too many in your app. – Omar Rehman Dec 15 '11 at 13:46
4

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.

Community
  • 1
  • 1
drekka
  • 20,957
  • 14
  • 79
  • 135
2

If you switch to Log.d, then you can debug your application, and when building a release version, none of those calls will be compiled or executed.

bfly2000
  • 198
  • 6
  • I need to edit this slightly, your the Log.d function is of course still pre-compiled into the dalvik vm; however, it will never execute the log function fully. You still execute the method call, but this call is of minimal impact, especially with 2.2's caching feature. – bfly2000 Apr 14 '11 at 02:35
1

Yes, it does have performance penalty. check this: Log.d and impact on performance

Community
  • 1
  • 1
Priyank
  • 10,503
  • 2
  • 27
  • 25
0

The answer is yes and no.

It depends on how many Log calls you have and as you're talking about step-debugging, I'm guessing you're not worried about release code at this stage (when you'd obviously remove excessive logging).

I've used excessive logging to the point it overflows the logcat but only when trying to track down a particularly elusive problem in my debug code - that logging was removed as soon as I tracked the problem down.

In short, log as much as you like in development but don't inflict it on the user.

Squonk
  • 48,735
  • 19
  • 103
  • 135