Log.d and impact on performance

Question

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

Newcomer

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. – Tabescent

Answer 1

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

Petasus

Why don't you set debuggable=false to disable debug in app: <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="false"> – Paederast

@Paederast 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. – Mayman

Even better, use Proguard to strip out all the logs from the code. – Bookmaker

I think the best solution is to use a third party loggin library such as Timber timber.io so you can customize your app log behabior depending if it is in production or debug mode. – Boart

Answer 2

My solution:

• Add unguarded log statements wherever you like
• Strip them out for release builds

Ashtoreth

by far the best solution IMHO - does not pollute code at all :) – Pointing

but then you cannot turn them on again – Varela

Answer 3

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

Bonesetter

Answer 4

Simply use code guard methods.

if (Log.isLoggable(LOG_TAG, Log.DEBUG)) {
Log.d(LOG_TAG, "Your log here");
}

Burmaburman

Even this check has performance implications. I just ran Traceview and Log.isLoggable() takes 5ms CPU Time/Call and almost 11ms Real Time/Call. – Bookmaker

You're right. But much better than writing a log info to disk. And the level is configurable through server's configs. – Burmaburman

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. – Bookmaker

Answer 5

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.

Gemmell