Castle Windsor are there any downsides?

Question

I have been looking into the Castle project and specifically Windsor. I have been so impressed with what is possible with this technology and the benefits of having a such a loosely coupled system are definitely apparent. The only thing I am unsure of is if using this method has any downsides, specifically in asp.net? for example performance hits, etc.

I am trying to make the benefits of this approach visible to my fellow developers here and am being hit with the following comebacks:

1. That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)

2. If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)

Rory

forums.asp.net/t/1488120.aspx – Baronial

Answer 1

To answer your questions:

1. That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)

• No, it does not. Most of the time it uses little reflection when you register the component. It may also use reflection while generating proxy type, first time you request a component from the container.

2. If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)

• It's all a matter of design. You don't want to have each and every object created by the container. You use it primarily for service dependencies. In this case, you don't care about what type is actually hiding behind the interface (that's the whole point of it, isn't it?).

You also can have class components, but they have limitations, and you must be aware of those (for example you can't intercept calls to non-virtual methods). I have found Windsor to be the most mature, and best suited to my style of development container of all.

Other than that, Performance, I haven't heard of a project that had to discard dependency container because of unacceptable performance. Windsor is really smart about it, and it caches the results of lengthy operations so that you don't have to pay the price twice. You may find charts on the Internet, comparing speed of many IoC containers. Two things to note about those: All containers are really fast. Don't think that the fact that other containers are faster on these charts than Windsor, means that they are better. Windsor does a lot of stuff for you that other containers don't.

Souse

Follow up question here. #2217184 – Obverse

Agreed on performance, as it can be a really low hanging fruit if you simply find a faster container. Take a look at this blog post for more detail - after reading this I switched to Funq and saw decent gains: palmmedia.de/blog/2011/8/30/… – Forelady

Answer 2

I've used IoC containers (Spring.NET and StructureMap) in several production apps under high load (not Facebook/MySpace high, but enough to stress out a few servers).

In my experience, even before I started using IoC, the biggest perf concern is the database and the interaction with the database -- optimizing queries, indexes, using 2nd-level caching, etc.

If you have a database involved with your app, then whatever performance hit Windsor or any other container may cause will be so infintessimally small compared to a DB round trip.

This is like people who compare the performance hit of the new() operator vs. Activator.CreateInstance() at 1-10ms when a single DB roundtrip is usually an order of magnitude more expensive.

I would advise you not to worry about the small stuff and concentrate on the big stuff.

Also, I'd like to advise you to look at StructureMap, as I believe it has a lot more functionality than Windsor and doesn't have a lot of Windsor's shortcomings (i.e. holding on to references and requiring you to release them, etc).

Seamstress

Hammett committed Component Burden a couple of months ago (mail-archive.com/[email protected]/…) – Aguedaaguero

-1. resource acquisition is intialization; how would you verify the lifetimes of your objects when there's no meta-data about the life-style that propagates across the resolve call? Or, what about disposable objects being depended on by what you are resolving; how would you make sure to release those manually? It's not a short-coming. In MVC, e.g. the release-part is coupled to either the controller or the per-request lifestyle, normally and Windsor handles it for you! – Oversleep

I've used StructureMap and Windsor and with Windsor I have to do a lot more messing with lifecycles and configuring it. With StructureMap, it just works. It handles all the same scenarios, but in a more obvious way. Windsor makes you think about it more which isn't necessary 99% of the time. – Seamstress

Answer 3

One problem with Castle Windsor I came across is that it is not able to run in Medium Trust (without recompilation which I was not able to do). So I needed to switch from Windsor to Unity.

According to DI/IoC performance - I believe that the performance hit is not large especially when you keep in mind the power it has.

BTW: If you are beginning with DI/IoC, you should read this MSDN article.

Dues

About compiling Windsor to run on Medium Trust, maybe this can help: vhendriks.wordpress.com/2007/11/21/monorail-on-shared-hosting – Aguedaaguero

Answer 4

Significant start-up costs, almost no performance hit during operation (no reflection for calls, of course - everything's compiled during instantiation). Windsor is a bit on a heavy side, but with proper lifetime management shouldn't cause any problems.

A more important downside is that integration problems are not caught during build, and some not even at launch. Without carefull tracking of all modules' versions and continuous testing of whole system it's easy to get in trouble. Reflection helps here, so Windsor is better in that aspect than many other DI frameworks.

Hultgren

Answer 5

The one exception where performance of an IoC container is unacceptable in my experience is when trying to integrate/wrap the IoC container as an IServiceProvider for use in the ComponentModel - a once common example of this was when creating your own hosted winforms designer (normally to build some kind of custom designer, i.e. workflow/flowchart etc.)

Due to the way a number of winforms components behave, especially at design time, the cost of resolving a component will physically cause the mouse to "stutter" when dragging because the framework can make upwards of 30,000 service resolution calls a second - this is more a reflection on poor coding practices in the components themselves though I think, or at least due to assumptions being made about the service providers implementation being fast/simple.

In practice I've never found component resolution times to be a problem in even heavily loaded commercial applications.

Pulp

Answer 6

Concerning the performance, see these articles:

• http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html
• http://www.codinginstinct.com/2008/04/ioc-benchmark-revisited-ninject.html
• http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html

But remember that some of these containers have newer (and probably faster) versions - especially Unity.

Dues

interesting reading as a comparison of IOC frameworks (which is great) but the last graph on the first link suggests the performance drop using IOC over "new" is considerable – Chittagong

Definitely, it must be slower than simple new operator. I agree that speed critical operations should be done without DI/IoC. But in most cases, it is a good deal for the abilities you get. – Dues

Moreover, think about absolute time of creating a new instance. Even if it takes 10x more time with DI/IoC, I think it is not the bottleneck of the application (unless you are creating millions of instances) and the performance hit is not remarkable (compared to the other operations). – Dues

alas, my immediate concern is indeed for an app creating millions of instances hence my fixation on the numbers - guess I'll try windsor on the next project :) – Chittagong

Windsor is a good place to start. Now I use Unity (better for use with Enterprise Library and Medium trust) – Dues

Speed of IoC containers is a non-issue for the vast majority of apps. The features each container has are way more important to do a comparison. – Aguedaaguero

Answer 7

1. That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)

As far as know all the good containers (Castle Windsor included here) do use reflection to create new instances. However this is improve performance. This is to compare with Activator.CreateInstance which is much slower. Some other Containers are quite fast though and can compete with the new operator. See comparison bench mark here. Castle Windsor is not from the high performant ones however the speed is not really important. When it comes to IoC use in application. 90% of your classes should be instated as singletones and this means work at the startup of your application only.

2. If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)

Try this tutorial and this tutorials. It will reveal answer to your question. If you want to avoid problems of design and easy to maintain software I would highly recommend going for SOLID practices

Horseweed