Should you remove all Debug.Logs from final release?

As an example if I just had:

Update(){
Debug.Log("Hello world");
}

And released the game. Could this end up crashing the game? For example, if the user had a Unity logger switched on and it would create a massive log file?

 

It won't crash anything, but it will DEFINITELY slow things down if you're logging every single frame. You should also be considering how your users will feel when their game grows by a gig or two every time they play your game.

 

I just assumed that when you compile the game for PC it just ignores all the Debug.Logs. I thought they were just for the editor. What happens to them then??? Is there a way to turn off them off globally just in case this kind of thing happens?

 

http://answers.unity3d.com/questions/126315/debuglog-in-build.html

 

The "Hello world" string is 11 characters, to that, add two characters for end of line (supposing the game run on windows) you have a total 13 byte of data.
Let's say you game run at 60 fps, then you have 13*60=780 byte/s written to the disk when the game is running.

Let's say the user hard drive is almost full and have 2 GB of freespace left.
Then the player could play about ((2^30)/780)/(3600*24) ~ 16 days before your game raises a
System.IO.IOException.

But don't worry, that's enough time for the player to have fun hearing it's hard drive spinning, get bored and quit the game.

 

Ah. I see. So I just should uncheck "Use Player Log" in the settings.

BTW. I wouldn't actually be silly enough to write code as above. It might be more on the lines of:

Update(){
doSomeServerCall();
}

OnErrorFromServer(){
Debug.Log("Server error");
}

Which is still pretty silly code. But if I miss it I wouldn't want the game to just freeze due to writing errors to the log file!

 

It wouldn't freeze; it would log the error. And that can be really useful.

So, in conclusion, you should remove silly/verbose DebugLogs from your builds, but leave useful ones that might help you understand what went wrong when a user sends you a cryptic bug report.

 

Plus the stack trace...

 

Oh yeah... plus the stacktrace ~ 7 Days.

 

What a stacktrace?

 

It's a list (a stack) of function calls that ends up to the current function.

It tells that the current function has been call from function A, which has been called from function B, ..., which has been called from the Main function.

It traces the stack of function calls.

 

Run a Debug.Log. Click on the message in the console. The stack trace is all of the info down the bottom that tells you where the message comes from. Its building this stack trace that is the slowest part of Debug.Log

 

Honestly, keep debug statements out of update, or anywhere it'll run every frame. I like to use them for state changes, file allocations, corner case behaviours, etc. It is slow...

 

Also precede all of your Debug.Log* statements with a check of Debug.isDebugBuild. This lets you make a beta/debug build with debug statements, or a final build without them, without having to touch any code or define symbols.

 

I was actually unaware of this before I saw it mentioned here. 10/10, would learn again.

 

Just to be clear,

commenting Debug.Log statements would just be fine before release? Wouldn't it?

 

There's a small performance hit every time you do a Debug.Log. You probably don't want that in your release other than instances when if you were to actually receive the log from a user that it provides helpful information.

So, recording of errors for example.

 

Yes, that would essentially delete the line as far as the program is concerned.
but as mentioned above, it can be useful to see what went wrong on the user end given a bug report so do use it in the build, but use it wisely.

 

Thanks guys!

 

I'm using this so there's no logging if the debug build is not checked.

Code (CSharp):

1.     void Awake()
2.     {
3.         //Disable logger if  not debug build
4.         Debug.unityLogger.logEnabled = Debug.isDebugBuild;
5.     }