25

I'm not entirely sure about what I'm reading in the documentation. Is it ok to leave a bunch of log.d pieces of code scattered about, or should I comment them out so that they don't impact my app's performance.

Thanks,

I'm a little confused because if you read about the log object (documentation) you see this:

"The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept. "

It almost sounded like it's ok to leave debug messages in there because they are "stripped." Anyway, thanks for the answers, I'll comment them out when I'm done. Not like I need them in there once the app is completed.

Thanks

Kushal
  • 8,100
  • 9
  • 63
  • 82
Andi Jay
  • 5,882
  • 13
  • 51
  • 61
  • 1
    Besides impacting your app's performance, they potentially make it harder for other people to debug their stuff. The log is only 64KB, so every time you add a log message some other message gets pushed off the top. – fadden Sep 22 '10 at 20:35

5 Answers5

19

Log has impact on performance, so it's recommended that you comment it out or log with conditional statements.

For example

public class MyActivity extends Activity {
// Debugging
 private static final String TAG = "MyApp";
 private static final boolean D = true;
 @Override
 public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if(D) Log.e(TAG, "MyActivity.onCreate debug message");
 }

Then in when you publish your release version just change "D" to false

MatteKarla
  • 2,707
  • 1
  • 20
  • 29
  • 3
    Why don't you set debuggable=false to disable debug in app: – anticafe Apr 14 '11 at 00:43
  • 12
    @anticafe Because if for example you do a concatenation in a Log statement, it will still run (causing unnecessary allocations). Settings `debuggable = false` only ensures that it won't end up in the log. The methods will still get called. – yydl Dec 25 '11 at 07:40
  • 3
    Even better, use Proguard to strip out all the logs from the code. – Christopher Perry Aug 12 '13 at 18:30
  • I think the best solution is to use a third party loggin library such as Timber http://timber.io so you can customize your app log behabior depending if it is in production or debug mode. – YuanOnLine Apr 10 '20 at 08:15
10

My solution:

Community
  • 1
  • 1
Christopher Orr
  • 110,418
  • 27
  • 198
  • 193
2

Simply use code guard methods.

if (Log.isLoggable(LOG_TAG, Log.DEBUG)) {
Log.d(LOG_TAG, "Your log here");
}
gconcon
  • 77
  • 4
  • 1
    Even this check has performance implications. I just ran Traceview and Log.isLoggable() takes 5ms CPU Time/Call and almost 11ms Real Time/Call. – Christopher Perry Jun 11 '17 at 23:36
  • You're right. But much better than writing a log info to disk. And the level is configurable through server's configs. – gconcon Jun 21 '17 at 15:10
  • It is definitely better than writing to disk, but not good if you're trying to render frames at 60fps consistently. It's taking a good chunk out of that 16.7ms per frame. – Christopher Perry Jun 21 '17 at 17:55
2

Definitely comment them out. They add up quickly and could noticeably slow down your app, especially if you have them in loops.

Chris Fei
  • 1,327
  • 8
  • 11
0

Yes print, println, Log.d, Log.e and all similar methods affect performance.

The solution

create a class named C

class C{
public static String TAG="My_debug_tag";
public static boolean isInTesting=true;

public static void log(String tag, String msg){
 if(!isInTesting) return;

Log.d(tag==null?TAG:tag, msg);
 
}
}

and use these methods for all your logs, and when you are ready to generate final .apk/.aab just set isInTesting=false to disable all logs from this method.

Nasib
  • 1,173
  • 1
  • 13
  • 23