Skip to content

Big Update on StructureMap 3.0 Progress

February 22, 2013

I can finally claim some very substantial progress on StructureMap 3.0 today.  For a background on the goals and big changes for the 3.0 release, see Kicking off StructureMap 3 from last year and some additions from last month when I started again.  As of today, StructureMap 3.0 development is in the master branch in GitHub.  If you need to get at StructureMap 2.6 level code, use the TwoSix branch.

What’s been done?

  1. I removed the strong naming.
  2. All the old [Obsolete] API methods have been removed
  3. The registration API has been greatly streamlined and there’s much more consistency internally now
  4. The nested container implementation has been completely redone.  It’s much simpler, should be much faster because it’s doing much less on setup, and the old lifecycle confusion between the parent and nested container problems have been fixed.
  5. The “Profile” functionality has been completely redesigned and rebuilt.  It’s also much more capable now than it was before.
  6. The container spinup time *should* be much better because there’s so much less going on and a lot more decision making is done in a lazy way with memoization along the way.  Lazy<T> FTW!
  7. There’s much more runtime “figure out what I could do” type possibilities now
  8. You can apply lifecycle scoping Instance by Instance instead of only at the PluginType level.  That’s been a big gripe for years.
  9. The Xml configuration has been heavily streamlined
  10. The old [PluginFamily] / [Pluggable] attributes have been completely ripped out
  11. Internally, the old PipelineGraph, InstanceFactory, ProfileManager architecture is all gone.  The new PipelineGraph implementations just wrap one or more PluginGraph objects, so there’s vastly less data structure shuffling gone on internally.

What’s left to do?

I’ve transcribed my own notes about outstanding work (minus the documentation) to the GitHub issues page.  There are a few items that are going to need some serious forethought, but I think the biggest architectural changes are already done and that list is starting to be more of a punchlist.  I would dearly love any kind of help, design input, additions, or feedback on the outstanding work.  If you’re inclined to get involved and tackle some of the issues, I tried to label the issues for the effort level.

If you think of the issues as picking a sword fight, the tags line up like this:

  1. “Easy Fix” – Facing a sheepherder who probably stole that heron mark blade he’s carrying
  2. “Medium Effort” – Fighting a Trolloc
  3. “Architectural Level Change” – Fade.  I will likely need to be involved with any of these

Fairly soon, I’ll be making a call for folks to try out a prerelease version of StructureMap 3 in their existing applications.  As part of that effort, I’d really like to get some feedback about the observed performance and see if we can beat on it enough to find any memory leak issues.

If you or someone you know is a multi-threading guru, I’d probably be interested in talking through some things with you in the codebase.

Docs?  Someday?  Maybe?

Hopefully someday soon.  The FubuMVC core team will be relaunching a completely new website sometime in the next couple years with our own implementation of a readthedocs style infrastructure.  I’m planning on making the new StructureMap documentation part of that website.  Documentation will be in git where it’ll be easy to take in pull requests for additions and corrections, and you’ll be able to use either Html or Markdown for the content.  We’ve already got a working mechanism to “slurp” code samples live out of a source code tree and put into the we pages with formatting via pretty print to achieve “living” documentation this time around.

 

Last Thoughts

I haven’t paid attention to any of the “IoC Container Performance Shootout!” type blog posts in a long time, but StructureMap used to routinely come in well ahead of the other full-featured IoC containers (tools like Funq shouldn’t be considered apples to apples with StructureMap/Windsor/Ninject/Autofac/whatever.  If you don’t support auto-wiring, rich lifecycle support, and maybe even interception, I say you don’t count as full-featured) in terms of performance.  However, as I’ve torn into the StructureMap codebase with an eye towards better performance for the first time in years, I’ve found a scary amount of performance killing cruft code.  My final thought is that as bad as the StructureMap code was (and trust me, it was), if it’s really faster than the other IoC containers, then what does that say about their code internals at that time?  ;-)

About these ads

From → StructureMap

7 Comments
  1. Maybe instances created per second is not the top priority when selecting an IOC container. Nice work, nonetheless!

  2. Maybe not the number of objects created per second, but the nested container performance problem is real, and the time it takes to initialize the container for bigger applications is a noticeable drag for me.

    Either way, a little performance boost won’t hurt anyone;)

  3. Jason Cavaliere permalink

    And Today I learned that we both like WoT…

  4. Scott Johnson permalink

    Hello Jeremy!

    Long time user of StructureMap, several projects using it under my belt personally. I have even been in attendance at the Austin .NET Users’ Group when you have presented.

    We are currently starting dev on a LARGE enterprise level application, and StructureMap has been chosen as the DI framework. Would like to be involved with your development and bringing the latest and greatest code into the fold, so we could possibly assist in your dev and also make sure you get something large scale to work with. If you are interested in some collaborative effort, please drop me an email.

    Thanks,
    Scott Johnson

  5. Hello Jeremy,

    We have investigated the memory usage of structuremap the last weeks. By disabling the SetterInjection in the codebase the initial memory footprint of our app is reduced by 30 MB.
    On an simple wpf demo app we can reproduce a symtom of the problem:
    A registered wpf control has a initial meomory usage of 120 KB (as Plugin Instances), as long as it was not instanced. When instanced the plugin instances drop to 2 KB memory usage.

    Perhaps there schould be an option to disable SetterInjection in SM to lower memory usage and speed up cotainer intializitation.

    We looking forward to the structuremap 3.0 final.

    Best Regards Andreas

Trackbacks & Pingbacks

  1. Dew Drop – February 25, 2013 (#1,504) | Alvin Ashcraft's Morning Dew

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: