Performance of logging system
When you insert a logging system into your application you should do some preliminary test for performance issue. The most important thing is that logging infrastructure should not introduce too much overhead when the log is disabled. With log4net you have different way to handle the log, suppose you have a logger and the DEBUG level is disabled; you can use one of these three form
|
|
The first version rely on the fact that log4net infrastructure internally checks if debug is enabled so you can call Debug function directly. The second technique is to check if log1.IsDebugEnabled before calling log1.Debug(), and the third stores the IsDebugEnabled in a local variable to check that variable instead of calling IsDebugEnabled each time. If you do one million log calls you will obtain these rough measurements in milliseconds.
|
|
Thus solution 1 and 2 are quite similar in performances, while the third version is obviously the winner because it has not to call the log1.IsDebugEnabled at each run.
Now suppose that the messages is not a constant string but it has to be build
|
|
In this situation the first test is important
|
|
The second and third results have the same timing as before, the log is disabled so both conditions evaluates to false as before. The important fact is that the first technique is much more slower, this because even if the debug level is not enable, you have to pay the time to do string concatenation to create the message to send to log.Debug function.
The conclusion is: always check if the log is enabled. Moreover do not forget to use log4net compiled in release mode to production code, the above timing with release version of log4net are the followings.
|
|
As you can expect, the release version have really better performance.
Alk.