|
I was assuming writing debug.log() would have no effect on the performance in the build. I noticed that my menu runned at about 4 fps in the editor, which turned to 500 fps after removing all the debug.log there. However, it seems that my menu also runs very slowly (presumably also around 4 fps) in the build when I still have these debug.log there. This leads me to believe that debug.log is still executed (but fails), rather than removed altogether. Is this the case ? because that would be quite annoying, as I'd have to remove all the debug stuff if I want to make a smooth build. EDIT: Apparently this is the case and intentional. Thanks for the answers guys. I think I'm gonna write a wrapper that's something like:
(comments are locked)
|
|
can't think of debug.log to cause such performance loss other than due to exceptions, but you may want to add a static variable that defines whether you wan't to log or not. this way you don't have to delete every debug.log within the code. Thanks. It caused such performance loss because I call it about 50 times per frame in the menu. And yeah, a way so I don't have to this manually would be better than just deleting or commenting it out each time. I think I'm gonna write a wrapper that's something like: static function DebugLog(text:String) { if (Debug.isDebugBuild) Debug.Log(String); }
Jun 05 '11 at 01:43 PM
Steven 1
(comments are locked)
|
|
I have definitely seen Debug.Log() be a performance problem. Even one can cause a little hiccup on a smallish platform if you have enough going on. One thing I should mention that took me a little while to realize when I did a similar solution to your DebugLog() function is that often I would end up doing something like: DebugLog("Here in Func() " + var1 + " / " + var2 + " / " + var3); The string argument is evaluated whether or not you eventually log them, and they tend to be slow too - especially with concatenation. String.Format() is better, but still, I've come around to commenting these things out when not needed, and using #if UNITY_EDITOR for those I heavily rely on.
(comments are locked)
|
|
Removing them all is one option. I would just comment them out, or you can do this like the scripting ref suggests: Right, see this page to see where the log output ends:
Jun 05 '11 at 01:18 PM
Bunny83
Thanks, so it is as I assumed. If it's intentional, I find it strange that unity calls it "Debug", as I would expect anything by that name to do nothing in the build. And yes, I meant "commenting them out" when I said "remove". I guess I best just make a wrapper for it, so I don't have to do this manually all the time.
Jun 05 '11 at 01:39 PM
Steven 1
Debugging doesn't end with creating a build ;) If you have Debug.Logs that really should only work in the editor you can include it in a preprocesser if-statement #if UNITY_EDITOR #endif
Jun 05 '11 at 02:26 PM
Bunny83
(comments are locked)
|
I just wanted to add a comment regarding making a static function to anyone considering it. By adding a static function, you are changing the call stack, specifically the top level of the call stack which is stored with the output message. As a result, you will no longer be able to double click on the editor output messages and be taken to the line of code from which the log originated, as you will instead be taken to the new static function you created.
You can get around that by making the static function into a DLL, or you can not bother with that at all and just turn off "Use Player Log" in the player settings. (I don't think that option existed when this question was originally asked.)