I wrote (heh) an empty trace listener for LAB and an empty appender for log4net and ran a couple of unit tests. While not nearly as dramatic as Loren Halvorson’s findings 4 years ago, the results weren’t exactly flattering from LAB’s perspective.

The unit tests wrote 100000 info level – not that it matters, after all we’re using empty appenders – log entries and timed the whole deal. Log4net’s effort took a respectable 153ms, while LAB’s time was a significantly longer 1396ms. I also tried actually writing the entries out, using FlatFileTraceListener and FileAppender on LAB and log4net respectively. The results: log4net 1450ms – LAB 4243ms. Not as dramatic, but relevant nevertheless.

Oh, and by the way, I’m not handing out a table of the dubiously conducted performance test results, because I’m mean and I want you guys to read my posts.

Going beyond performance, setting up LAB is – to put it gently – laborious. Microsoft’s documentation doesn’t offer configuration examples in their native xml form. Rather, they “encourage” you to use a configuration tool that is shipped with Enterprise Library. That sucks. I had to download and install Enterprise Library to use a tool to edit App.config, instead of just copying the DLL from a project I already had and modifying a copypasted configuration to suit my needs. I hate clicking around to produce stuff that’s essentially lines of code in my Visual Studio solution.

Then there’s the behemoth of an API that LAB sports. Constructing LogEntry objects, then asking whether it should be logged and then writing them out to the logger isn’t actually succinct. Surely you can encapsulate this behavior in your own helper methods, but I can hardly see the point in rewriting the API. Logging code should be really succinct, and by default log4net’s API provides ways to do just that.

log4net 1 – MS Logging Application Block 0

ps. Do note that Enterprise Library 3.1 is already outdated so I don’t know if these conclusions apply to Enterprise Library 4.1.