What performance overhead do IoC containers involve?

Question

Hi,

Loose coupling is wonderful of course, but I have often wondered what overhead wiring up dynamically using an IoC container (for example Castle Windsor) has over a tightly coupled system?

I know that a detailed answer would depend on what the IoC was being used for, but I'm really just trying to get a feel for the magnitude of effort involved in the IoC work.

Does anyone have any stats or other resources regarding this?

Thanks

Answer 1

There is links about performance
http://realfiction.net/?q=node/143
There is a results

• Normal construction: 0.0001 / 0.0002
• Activator construction: 0.0069 / 0.0071
• Container construction (Castle Windsor): 0.1014 / 0.1068
  
• Container construction (Spring.NET): 0.069 / 0.0722
  

But as you can see the Windsor isnt the fastest IoC (Autofac much faster)

The correct answer is, the performance doesn't matter :).
Because the correct using of IoC ,when all registering process is at initializing stage.
In other words the using of IoC must reducing the count of your "if else" in real-time.

Answer 2

You'll have slower initialization times, as everything is loaded when the container is started. If init time doesn't matter to you, everyone's a winner on that chuck-a-luck wheel.

Answer 3

The best way to understand how complex an IoC container is comes from analyzing it.

In a particular experience, once I took an entire afternoon debugging some simple 'Hello World' code using plexus, which Maven is based upon (and here is a helpful link to browse its source code). It kinda came up (by looking at defaultPlexusContainer) as:

• Classpath Configuration (via classworlds)
• Creation of a Runtime Context Variable (basically a map), in order to store properties and variables
• Configuration Parsing (discovery of modules metadata on classpath, etc)
• Initialization:
  • Construction / Instantiation of Services
• Firing additional ComponentDiscoverers
• Firing of additional ComponentDiscovererListeners

This leaves an important aspect, deep into the steps above: Looking up a component. In plexus, the Phase concept wraps the steps for the construction of an Object, and those Phases are usually bound to a Personality concept. However, for the default setting, this is done by executing the following phases:

• Object Instantiation (i.e., new Object())
• Log Enabling (i.e., setting a logger for the object)
• Composition: i.e, dependency lookup and setting
  • The setter strategy is an interesting point, but I will leave the details for now
• The passing of the Context into the created object
• The object additional startup procedure

Most of those steps are optional, and usually involve identifying a given interface and calling it on the target object - this is the default for the plexus personality, note that.

Also, each object might be bound to a lifecycle manager, which mostly makes the difference between a new object and a singleton.

In my particular record: The most difficult part is actually parsing the configuration, and booting the container. After that, you're likely to notice no further difference in performance.