Want to use Unity + SignalR, Concerned by IsRegistered Performance

Aug 22, 2012 at 5:44 AM
Edited Aug 22, 2012 at 5:52 AM

In reference to the following:

Stack Overflow on SignalR + Unity -
http://stackoverflow.com/questions/9714273/using-unitycontainer-as-signalr-dependency-resolver
or
http://stackoverflow.com/questions/11358147/creating-a-unity-dependencyresolver-for-signalr

This Thread here on CodePlex:
http://unity.codeplex.com/discussions/268223

And Related Blog Post:
http://philipm.at/2011/0819/#regcheckalt

It seems the official stance on IsRegistered at the moment is that it's only intended for debugging and therefore should be slow? But in this Stack Overflow article it seems clearly necessary to facilitate resolving the dependency.

So given the horrid performance of the method's current implementation is there a better way to facilitate Dependency Resolution between these two technologies? Or can we expect to see a drastic improvement to this method's performance in 2.1 or 3.0, or maybe 2.2 and 3.1? Or should I simply abandon Unity for this use case? I'd prefer not to, I like the technology, its performance otherwise, and the plethora of neat extensions it offers...

Please help.

Aug 23, 2012 at 5:03 AM

As far as I know there are no plans for any changes to Unity 2 or 3 for IsRegistered (but bear in mind that I'm not privy to those internal discussions).  Perhaps in Enterprise Library v6, though?  Maybe I missed it but I don't even see an issue logged in the issue tracker for this.

I did see this post: http://unity.codeplex.com/discussions/248272 which has a code change to improve performance.  If performance is not adequate then you could try that fix.

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com 

Aug 25, 2012 at 6:18 AM

I guess I'll have to fork Unity then.

 

Thanks for the heads up!

Aug 25, 2012 at 6:35 AM

In case you missed it, Unity vNext planning is starting so now would be a good time to make suggestions: http://unity.codeplex.com/discussions/392820.

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com 

Aug 25, 2012 at 6:53 AM

I added this and a suggestion for a set of common Aspects over at http://entlib.uservoice.com/forums/89245-general. Again, thanks for the heads up!

Sep 7, 2012 at 5:10 PM

I would also suggest that there's nothing wrong with doing the try/catch approach instead of an IsRegistered check.

The thing to remember about IsRegistered is that it only checks for registration, it's not CanResolve. Unity can resolve types that aren't registered.

I would recommend just doing the try/catch instead of checking with IsRegistered first. In the case where Unity can resolve it you haven't lost any performance, and in the case where Unity can't resolve (and thus an exception) I expect the perf hit will be on par with the if and traversal of the registrations. Measure to be sure.

 

Sep 8, 2012 at 8:34 AM

The try...catch scenario is actually covered in Phillip's performance testing linked in the initial post at http://philipm.at/2011/0819/#regcheckalt and makes IsRegistered look highly optimized and blazing fast by comparison. I appreciate the suggestion though, a work-around would be desirable, though an out right address of the issue in the next version would be even better!