Unity startup performance

May 6, 2011 at 11:40 AM

I am developing a desktop application depending on the Entity Framework for data access and on Unity for dependency injection. I am trying to cut down its startup time, currently at 40 seconds for the automatically driven “startup + two consecutive database accesses, no UI” scenario. The data model has over 300 entities, and the Unity configuration consists of about 7000 registrations (which I am doing programmatically, no XML configuration here). The 40 seconds consists roughly of 20 seconds for Unity configuration, and the other 20 for EF initialization on first database access – the second access takes milliseconds and is negligible in this case. The EF’s 20 seconds goes down to 4 if I pre-generate the ESQL views as documented, but I see no obvious way to optimize Unity configuration. I thought the Unity startup time comes from its Reflection.Emit  usage, but I found out that the dynamic build plan methods are compiled on first resolve – not on registration. Profiling revealed that the most expensive operation during the ~7000 .RegisterType calls is PolicyList.ClonePolicies(). It seems that access to this structure (through .Set and .Clear) is being guaranteed to be thread-safe all the time, even if type registration is supposed to be not, as detailed in several threads here (for example, this one: http://unity.codeplex.com/discussions/27496 ). If I replace the ClonePolicies() method body with “return policies;” the performance of type registration increases so that the configuration is done in 2 seconds, I observe no obvious side effects (Unity unit tests all pass), but since the PolicyList structure is used later on during Resolve operations, which are supposed to be thread safe, I’d need to implement some kind of flag that sets the container back to “thread-safe mode” after configuration is done for the solution to be complete. My question is, since I don’t know very much about Unity/ObjectBuilder gory internals, won’t that break anything I am not aware of? Am I not missing a more obvious solution to the “Unity startup performance” problem, apart from “register less types”?

May 9, 2011 at 2:12 AM

Hi,

From your statement "but I found out that the dynamic build plan methods are compiled on first resolve – not on registration" do you mean it taking up more time on resolving? If yes, is there by any chance you were able to see this other thread (http://unity.codeplex.com/discussions/255250) and see if it somehow helps on improving the performance.

As for the changes made in the Unity source code we couldn’t tell what any possible drawbacks, the Entlib team may have more inputs on this.

Gino Terrado
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com

May 9, 2011 at 6:04 AM
AvanadeSupport wrote:

Hi,

From your statement "but I found out that the dynamic build plan methods are compiled on first resolve – not on registration" do you mean it taking up more time on resolving? If yes, is there by any chance you were able to see this other thread (http://unity.codeplex.com/discussions/255250) and see if it somehow helps on improving the performance.

As for the changes made in the Unity source code we couldn’t tell what any possible drawbacks, the Entlib team may have more inputs on this.


Yes, I did mean that the first resolve of a registration takes a little more time that the subsequent ones, but that isn't the cause of my problem, because:

  • I have issues with the registration performance, not resolve performance,
  • the hit on the performance on first resolve due to the dynamic method compilation is very small.
May 13, 2011 at 3:20 AM

Agree, I believe the first resolve could probably be slower than the next or later.  We don't know what could be the performance penalty of each registration though given that you have ~7000 of it I would think there would have. How about trying out to measure a few registration first and see if it calculates to the same amount of performance hit you are getting on the actual ~7000 registrations. Though, personally I really don't know any other approach to optimize this other that with those related thread I posted initially.

Gino Terrado
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com