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. --- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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]
