Hi,
Absolutely. I did a quick test case, but the really interesting thing is that it takes roughly 200 ms for it to run (creating 25000 viewmodels with roughly the same level of complexity as in our “real world” scenario). I checked it a bit further and it turned out that the problem at hand occurs because we are doing reflection on the type we are intercepting etc. every time an instance is created. Needless to say, this becomes a massive performance bottleneck. When I commented out all of the reflection stuff, we are down to 1 second (from a previous figure of 50 seconds, as mentioned below), so I think I’ll try to solve this by caching as much as possible of the reflection-related stuff, to avoid having to do it over and over again… Thanks anyway! :-) Best regards, Per From: [email protected] [mailto:[email protected]] On Behalf Of Krzysztof Kozmic Sent: den 26 juni 2012 01:51 To: [email protected] Subject: Re: Performance issues when using proxies, interceptions, mixins etc... Can you build an isolated case for that that reproduces the issue? On 26/06/2012 3:19 AM, Lundberg, Per wrote: Hi there, We are using Castle Windsor for all our projects with great success, in almost all aspects. However, we have one slight issue with it: performance. Sometimes, when we are deserializing a big result from one of our REST services for example, we see this as a noticeable lag in the responsiveness. I did some quick testing and theres clearly something fishy here. This code: public void PerformanceTestTransientViewModel() { for (int i = 0; i < 25000; i++) { //viewModelFactory.CreateViewModel<TransientViewModel>(); container.ResolveType<TransientViewModel>(); } } ..takes more than 50 seconds to execute. (container is an extremely simple wrapper on top of Windsor, because we dont expose Windsor to our applications directly.) We are using the typed factory facility (ViewModelFactory is generated using this approach), and I suspected the problem was with the typed factory stuff. But, as you see, I tried it with plain container.ResolveType which is in essence windsorContainer.Resolve<TFrom>() being called, and it was equally slow. Any hints? What weve done sometimes is skipped the proxying/interception in these cases, and instantiated the classes automatically (without even registering them in the IoC) which is a lot faster, but Id rather not have to that on a massive scale. Many thanks in advance for your ideas! I can show you more about how exactly we are setting up the Windsor Container if you like, but its fairly complex (since we have our own application framework running on top of Windsor), so its probably best to look at the specific parts that are relevant. Best regards, Per -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
