You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-user@logging.apache.org by Schweizer Andreas <an...@elca.ch> on 2005/05/30 10:46:12 UTC

A couple of questions and comments

Hi list!

We're considering using log4net as a replacement for our own logging
infrastructure in our companies framework for developing business
applications. I've compared log4net with our own implementation and have a
couple of questions and things that may be interesting to add to log4net in
later releases. 

First, let me congratulate you for the nice job that you've been doing in
developing log4net. It is very intuitive to use, provides many interesting
features and is very well documented. My points are not meant to affect you
in any way ;-) :

1. In the ILog interface, log4net provides methods with open argument lists
(DebugFormat etc.), but IIRC the params keyword of C# is not CLS compliant.
What is your attitude towards CLS compliance?
(In our "old" logging infrastructure, we separated the members into two
interfaces, ITracer and IClsTracer, with the second one containing only CLS
compliant members. An idea would be to have two separate calls,
LogManager.GetLogger and LogManager.GetClsCompliantLogger, to get the two
different interfaces.)

2. I've seen that you call String.Format relatively early, i.e. before
calling Logger.Log(...) from the main logging methods (DebugFormat, etc.) in
the LogImpl class. As String.Format can be time-consuming, performance could
be improved by delaying this operation until after you call IsEnabledFor in
Logger.Log (to avoid calling String.Format for messages that get filtered
out by IsEnabledFor). 

3. LocationInfo uses StackFrame and StackTrace to find the method that
triggered the logging event. A way to improve performance would be to pass a
MethodBase instance as an argument to the logging methods, and even re-use
that object for subsequent calls of logging methods from within the same
user method.

4. Conditional overloads would be nice to have, e.g. FatalIf(bool cond,
...), that only generate the logging event if cond evaluates to true.

5. As stated in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht
ml/cpconmethodusageguidelines.asp, performance could be improved by
providing dedicated overloads for a small number of arguments, e.g.
DebugFormat(string format, object arg1, object arg2).

In our applications, typically one in ten instructions is a call into the
logging infrastructure, so the performance of the logging infrastructure is
critical for us.

I'm looking forward to reading your answers :-)
Andy