Re: RoutingTableRepository

[Jaroslaw Kowalski <ja...@jkowalski.net>]

> A very oversimplified explaination of what's going on is that log4net
> must look through the hierarchy to determine how to process the message
> while NLog does a string comparison on the logger name to see if it
> matches the current rule. The routing table approach would process
> logger nodes one at a time by starting with the first one and working
> its way down (similiar to how filters work). I would imagine most of
> NLog's speed improvements (I believe Jarosław tests have shown
> that NLog is in the neighborhood of at least 3x faster against each
> system's null appender/target) over log4net are a result of this
> simplified comparison.

It's not exactly like that. The routing table processing happens only at 
configuration time, not at runtime.

NLog uses a routing table in the config file, but it precalculates the chain 
of targets(appenders) and filters that should be walked for each 
(logger,level) combination and stores the chain in the logger itself.

This way checking whether logging will be effective is very cheap (check the 
length of the chain). NLog makes it even faster by precalculating the flags 
for all supported levels (there's a fixed number of them in NLog). This way 
logging statement elimination is effectively a single boolean comparison 
which occurs in a non-virtual function. I don't think you can do it any 
faster.

I believe that something similar can be done with log4net, if you choose to 
do so.

There are issues, which should be considered:

* every change to the configuration at runtime requires all the Loggers to 
be reconfigured (by notifying them that that configuration has changed). 
NLog's LogManager keeps a list of all constructed loggers, so that they can 
be notified when the configuration changes. Fortunately NLog's configuration 
mechanism is atomic, so this isn't an issue with programmatic configuration.

* keeping a pre-constructed chain of targets costs memory. If you have large 
number of loggers, you may (seemingly) leak memory, because all logger 
references are kept in a hashtable. This will be addressed in post-1.0 
releases by merging(interning) the chains that are effectively the same 
thing or even converting them into weakrefs.

--
Jarek
http://www.nlog-project.org/