NSLogs are great when debugging to see exactly what is going on but the downside is that they impact heavily on performance (I speak from experience on that one).
Luckily there is a way to "disable" them on release builds of your application and still have them in your debug builds. we do this by simply adding the following macro to the prefix .pch file in your project or anywhere before the entry point to your application.
If you want an explanation here it is.
When you build a Debug version of an application DEBUG is defined , if its a release build , DEBUG is not defined.This macro checks if DEBUG is defined , if it is it sets NSLog to what it should be , if DEBUG is not defined then NSLog is defined as an empty code block that as you should know will do nothing , thus saving on performance.
Luckily there is a way to "disable" them on release builds of your application and still have them in your debug builds. we do this by simply adding the following macro to the prefix .pch file in your project or anywhere before the entry point to your application.
#ifdef DEBUG
#define NSLog(...) NSLog(__VA_ARGS__)
#else
#define NSLog(...) {}
#endif
When you build a Debug version of an application DEBUG is defined , if its a release build , DEBUG is not defined.This macro checks if DEBUG is defined , if it is it sets NSLog to what it should be , if DEBUG is not defined then NSLog is defined as an empty code block that as you should know will do nothing , thus saving on performance.
Wasn't aware that NSLog caused any performance issues if left in production code. Once again, thank you for posting this.
ReplyDelete