1

I'm using Spring.NET and running into problematically long Ioc Container load times. The app context config only has a few (like 10 objects), yet it takes sometimes up to 20 seconds to load the container. I can see in the debugger this time appears to be attributed to loading lots of (DDLs?) with odd names. The end result is the Windows Service takes to long to start and the IT operators think it's hung.

What can I do to avoid this. I've tried "Just My Code". Any ideas?

'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded '0xclmvcv'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'rpuvyhdh'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'sq10jbae'
'Forge.Enterprise.Infrastructure.Scheduling.Server.vshost.exe' (Managed (v4.0.30319)): Loaded 'tmpk4bvl'
Marijn
  • 10,367
  • 5
  • 59
  • 80
Jerico Sandhorn
  • 1,880
  • 1
  • 18
  • 24
  • Could you post your configuration file? – Marijn Nov 14 '11 at 15:08
  • Those dll names look a lot like dynamic dll's created by .Net's [`XmlSerializer`](http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx); but they could be generated by something else. For Aop, spring dynamically creates proxies, but the name of that dynamic dll is usually `Spring.Proxy`. [This question](http://stackoverflow.com/questions/2394699/net-dynamic-assemblies) has an answer with some other sources of dynamic dll's. – Marijn Nov 14 '11 at 15:26
  • It turns out this was an issue with the slowness of Reflect.Emit, especially when emitting methods that have non-void return types. In this case, the cost is about 1-2 seconds for each method. Your right about the XmlSerializer DLLs, these were for our Data contracts annotated for XML serialization – Jerico Sandhorn Nov 15 '11 at 19:42
  • Was the slowness related to spring.net (aop uses Reflection.Emit), or to other code? Did you solve it and how? – Marijn Nov 15 '11 at 22:09
  • Marijn,the slowness was in .NET c# Reflect.Emit used explicitly. We use it to generate proxies that implement our ServiceContract one-way operations so they flow over NMS+ActiveMQ instead of the transports supported by WCF. The request/response only differs by having a return type instead of void, and for those, there was a 200-400ms cost for each method. So I split out the one-ways to separate interfaces so they don't get proxied. That said, I would not be surprised if spring AOP suffers from the same performance issues .. but perhaps only for DataContract arge/return types. – Jerico Sandhorn Nov 29 '11 at 12:25

1 Answers1

1

I was asked to share the comment above as an Answer for others to find useful.

The slowness was in .NET c# Reflect.Emit used explicitly. We use it to generate proxies that implement our ServiceContract one-way operations so they flow over NMS+ActiveMQ instead of the transports supported by WCF. The request/response only differs by having a return type instead of void, and for those, there was a 200-400ms cost for each method. So I split out the one-ways to separate interfaces so they don't get proxied. That said, I would not be surprised if spring AOP suffers from the same performance issues .. but perhaps only for DataContract arge/return types

Jerico Sandhorn
  • 1,880
  • 1
  • 18
  • 24