Big Update on StructureMap 3.0 Progress

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?  😉