0

I've been having a hard time finding information on this subject in both outside research and on StackOverflow/Progammers.StackExchange so I figured I'd ask here. This it mostly a 'best practice' question, but I am interested in the performance repercussions as well.

Background:
I currently am using the NLog logging framework in a WinForms application with a supporting Windows Service component. I have a lot of tracing log statements throughout the application for my testing which I monitor via UDP output. Errors/Warnings also go to the Event Log and rolling log files, which also include the INFO level as well.

Question:
What is the best practice to handle all of the logging code when compiling the release version of the application? Should all trace/debug code be removed from the application since it could negatively affect performance? Since NLog logging is controlled by XML configuration files, would removing the listeners for trace/debug logging eliminate the potential performance pitfalls? Should I have been placing trace/debug logging elements within preprocessor directives to prevent them being compiled into releasable production code?

JNYRanger
  • 6,829
  • 12
  • 53
  • 81
  • I can suggest you to take a look briefly on my article, regarding the typical logging mistakes. It can help you to boost application performance in the logging layer: https://medium.com/@imanushin/typical-logging-mistakes-4771fdf0f2d8 – Manushin Igor Jul 29 '19 at 10:04

1 Answers1

1

What is the best practice to handle all of the logging code when compiling the release version of the application?

You can leave your logging calls like it is and control the behavior with the log levels.

Should all trace/debug code be removed from the application since it could negatively affect performance?

You are right, logging affects performance negatively. How much depends on how often you log and the logging output. You should limit your logging to critical stuff, that helps in diagnose certain things or troubleshooting a problem/exceptions.

Since NLog logging is controlled by XML configuration files, would removing the listeners for trace/debug logging eliminate the potential performance pitfalls?

Yes. If you set the log level to Off then you gain performance. Because there are, for example, no IO oprations any more. The only cost is the check for loglevels within the logging framework.

Should I have been placing trace/debug logging elements within preprocessor directives to prevent them being compiled into releasable production code?

This would improve performance again. But than you are unable get any diagnostic information in production for troubleshooting a problem. This would be possible when you work with the log levels.

CodeTherapist
  • 2,776
  • 14
  • 24
  • I to concur with the pre-processor comment. @JNYRanger Leave your logging in and use a `TraceSwitch` or similar mechanism to turn logging on and off through config/commandline. – Gusdor Jan 09 '14 at 15:25
  • @Gusdor The NLog framework provides XML config files that control the logging output based on levels (or other info). Based on what you're saying it sounds like you agree with @C Sharper that just editing the config is the best way to handle it and deal with the extremely minor performance degradation that comes with the framework determining that those levels do not need to be output. – JNYRanger Jan 09 '14 at 18:40