logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Performance #'s for Log4Net and some ideas about how they can be improved
Date Sun, 23 Jul 2006 20:46:38 GMT
Jaroslaw Kowalski has written benchmarking code for NLog:

http://svn.nlog-project.org/repos/nlog/trunk/NLog/tests/NLog.Benchmark/

that tests a variety of logging scenerios. The tests can be configured
to report on comparable NLog, log4net, and EntLib LAB configurations.

Have you run log4net through a code profiler? You may be surprised find
that code that looks slow is not the same code that is responsible for
poor performace. dotTrace and ANTS Profiler are two good tools:

 http://www.jetbrains.com/profiler/
 http://www.red-gate.com/products/ants_profiler/ 

I discovered that calls to ReaderWriterLock.AcquireReaderLock() were
more expensive than code I thought was going to be slow. As for the
for() loop in the Hierarchy repository...the class is by design a
hierarchly structure containing parents and childerns. At some point,
it needs to walk the tree to look for items. If the for() loop is only
executed two or three iterations I doubt there will be much improvement
by trying to refactor the loop into a non-loop.

Of course making things faster isn't just about fixing what the
profiler found to be slow. Are you able to create a diff against the
trunk using your modified class?

I'm very open to improving performance so long as it doesn't break (or
breaks as little as possible) existing code. The log4net-dev list is
probably a better place for discussions like this.

--- "mjones@imagehawk.com" <mjones@imagehawk.com> wrote:

> I've written some small sample code because I wanted to see how bad
> the 
> performance hit was between
> 
>                     if (log.IsDebugEnabled)
>                         log.Debug(Message);
> 
> and
> 
>                         log.Debug(Message);
> 
> My thoughts on the issue were that the cleaner code is what I would
> like 
> to have in my projects even if there were a slight performance issue.

[snip]

Mime
View raw message