Comments on the EntLib/Log4Net feature and performance comparison

I know a few people have been waiting to hear our team's thoughts on Loren Halvorson's comparision of the Enterprise Library Logging & Instrumentation Application Block and Log4Net. So here goes...


First, let me state that we do not consider Enterprise Library to be a competitor to Log4Net – we think it’s great that both solutions exist so customers can pick whichever best meets their needs. We also see Log4Net and Enterprise Library as targeting different scenarios (something that isn’t really captured in the comparison) – for example it seems that Log4Net is optimized towards simpler scenarios for sending freeform messages to log sinks, while EntLib puts more focus on the types of things we see in more complex enterprise applications, including request tracing, gathering of additional context information, internal instrumentation through WMI and perf counters, and support for “operations friendly” log sinks like WMI and (coming soon) ETW. This doesn't make Enterprise Library better (or worse) than Log4Net, but it does mean that the best tool for one app may not be the best for another.


Regarding performance, as Loren himself points out this test doesn’t reflect any normal usage patterns so you can’t really draw many conclusions from it (does anyone really need to send 10,000 messages to the void in a tight loop?). Even testing a more realistic scenario is still likely to be of limited use, as every application has its own usage pattern and environment. For example, we did extensive performance testing of Enterprise Library on our hardware in what we saw as a typical usage pattern (i.e. writing messages once per transaction to the event log and other sinks from a web app with externally-generated load) – but your own application will use logging in a different way (different sinks, different message sizes), will run on different hardware, and most importantly will have different performance goals. This last point is important – the point of performance testing and tuning isn’t to make your apps run as fast as possible (which is a futile activity, as you never know when you are done) – it’s to run within your app’s performance goals. Everything your app does, including business logic and cross-cutting things like logging will take time, but if everything happens within your goals then you’re done. So our recommendation here is to choose whatever logging solution meets your needs (be it EntLib, Log4Net, System.Diagnostics or something else), use it intelligently, test early and often against your performance goals, and optimize (or change course) if you run into trouble. (See for more on this!)


Now you may be thinking that I’m dodging the question and looking at a career in politics here – yes it is obvious that in the particular scenario that was tested, Log4Net has some efficiencies over EntLib. I’m not disputing this, and there may well be some opportunities to optimize EntLib in the next version (which we’re working on now – you can submit your ideas as comments to my earlier blog posting). Still my point is that you cannot draw any conclusions from this test on whether this makes EntLib or Log4Net better for your app – the only way to get this information is to do your own homework, taking your own app’s functional requirements and perf goals into account.


Finally, we are aware that the startup time can be an issue in Enterprise Library – especially for smart client usage (for a server, the app starts so rarely it’s probably not a big issue). This will get better with .NET Framework 2.0, but in the meantime we released a custom configuration transformer class that can use Mvp.Xml’s precompiled serialization classes to dramatically improve the startup time. You can download this transformer and other additional configuration providers at the Enterprise Library community site (you need to be a member of the community and signed in to see the Releases section of the site).


This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (24)
  1. Akshayk says:

    EntLib sucks.

    Its so complicated.

    Its unnecessarily overEngineered as if to prove some point.

    Oh ya lets implement all design patterns here.

    Keeping things simple is something Ent lib guys forgot.

    Have u looked at numerous config files. yuck.

  2. .Net Adventures says:
  3. Ian Thomas says:

    A PlugIns framework.

    I reckon it’s a great future-proofing mechanism, but since everyone does it differently, it becomes a very messy operation.

    Some use XML config files, some use the registry, others expose an attribute, yet others try to impose a folder structure in the deployment.

    A lot of software uses standardized plugins, as we all know. All I’m asking is a standard framework with EL2 that provides a common base.

  4. Interesting post.

    I’m just doing a research about Logging EntLib block and the Log4Net 🙂

    I don’t agree with Akshayk EntLib sucks, but he have a point about the complication issue. But as with all new ideas, solutions, frameworks all seams complicated till u understand them fully 😉



  5. dls says:

    I should know better than to feed the trolls…. Over engineered two words; additionally, in a library–perhaps more properly a framework–that has a goal of extensibility, pattern oriented design is exactly what is required for the framework to survive multiple releases with its architecture intact. In this case, and possibly in many others, simple is at odds with a useful and complete architecture.

  6. Mike Gale says:

    Good post Tom. I also liked Loren’s.

    I’m after a clean migration path. (Both directions.) In my target scenario:

    1) I check in code whether I need to log.

    2) Configure on the fly, no restart.

    I’d appreciate it if there was a carefully thought out ILogging interface so that I can switch with less pain.

    Do you have anything in the works?

  7. amar says:

    nice post…have done logging thru’ log4net

    but would like to learn more about EntLib

  8. David says:

    I share some of the concerns on complexity. I know there is a line to walk between features and implementation, but something that is full of "concepts" can be rough to get rolling.

    The main problem with something that is complex in nature is the shelf life of the product. History shows (especially in the MS land) that the applications long outlast the technologies. I mean look at the initial application logging block that is now debunked and replaced with this one. And there is no correlation between the two.

    It is easy to understand someone being trepid about using it…

  9. guido says:

    I agree that performance of logging itself is not so important in most scenarios.

    What is important though is that logging comes back as quick as possible if turned OFF.

    In my test, 100000 calls in a loop cost as much as 6 seconds. Again, this is when no logging occurs.

    Which in praxis means to me that for debug-tracing you can just as well go back to printf statements, since you have to comment the stuff out later anyways.

    The possibility to ask the logger, if he is going to log is essential as noted in other posts and was also there in EIF.


Comments are closed.

Skip to main content