Potential performance issue with OB2

Oct 16, 2008 at 5:28 PM
We have an enterprise application based on CAB, and I have updated it to run an unmodified version of Object Builder 2 from build 12582.  It's not running Unity (yet).  Our application is running great so far; however, I did some performance analysis, and found that the new PolicyList implementation internally copies the dictionary on write, even though this Dictionary<,> is not externally consumed or copied to other PolicyList instances.  This is adding quite a bit of overhead every time the policy list changes, as our application builds a significant number of types through the system.  This should also be a concern if this is hosted in a web environment, as it will generate a lot of garbage.  The original version of PolicyList in OB did not copy the dictionary every time.

Cheers,

Stu
Oct 16, 2008 at 8:11 PM
The copying is for thread safety. The other choice would be to lock every time the policy list is accessed, read or write, which in our perf tests was much worse due to excessive lock contention. This way, you only need to lock when writing to the policy list, which happens a lot less than reading.

It's the usual trade offs. Even if for most the trade off is worth it, for some it'll hurt. I'd be curious to see what your results look like.


Dec 28, 2009 at 4:50 PM

The PolicyList.Set is killing our web app too!  We have a single object registered as PerRequest which takes 3 other dependencies.  When we profile our app for 800 requests we see 3200 calls to context.PolicyList.Set which takes 212 seconds.  About 50% of the total time to process the request.  We have several hundred, maybe a couple thousand items in the policy list and besides killing object resolution time its causing the GC to go nuts.

This needs to get fixed in 5.0 otherwise using Unity with a lifetime with anything other than singleton is not usable.

Dec 28, 2009 at 8:43 PM

Are you creating a child container on every request? That's the only way I can think of to get the behavior you're describing. Per request child containers turn out to be a bad idea for exactly this reason - "warm up" performance of the container can be bad as we do all the reflection and codegen and caching and whatnot. When you use a per-request container, the now-primed cache gets thrown out with the child container, and you pay the costs over and over and over again.

If your goal is just per-request lifetime, you're better off using one container and a per-request lifetime manager that stores stuff in HttpContext.Current.Items instead. There are tons of examples of this out there. If you're doing something else, there's probably a better way to do it that doesn't trash the caches and cause all this copying.

 

Apr 14, 2012 at 12:02 AM
scarnie wrote:
We have an enterprise application based on CAB, and I have updated it to run an unmodified version of Object Builder 2 from build 12582. 

Could You please describe main steps how to migrate CAB to Unity? We are trying to make this step but unfortunatelly without success.

Apr 14, 2012 at 7:57 AM
karelkral wrote:
scarnie wrote:
We have an enterprise application based on CAB, and I have updated it to run an unmodified version of Object Builder 2 from build 12582. 

Could You please describe main steps how to migrate CAB to Unity? We are trying to make this step but unfortunatelly without success.

Unfortunately, it has been a few years since I completed this task, and I'm no longer with the company.  It is a reasonably complex task, that requires a very good understanding of CAB / ObjectBuilder and Unity / OB2.  You are going to have to refactor some internal components of WorkItem to use Unity (and related OB2) such as the container.

Good luck with your conversion!