Hey, This is actually not a Castle Dynamic Proxy issue per se. That's a result of... BCL's unfortunate implementation of algorithm that looks for name collisions in generated assembly. The algorithm is not linear, so you see the performance decrease you described, as there are more and more types in the assembly. I created a connect ticket for that https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=472622&wa=wsignin1.0 In Mono this is probably implemented better, since as you described there is no perf degradation. Please vote for it, to show Microsoft that this is a serious issue.
Now, LinFu creates a new assembly for each new proxy type it generates so it does not take that performance hit. There are two things you can do to improve this situation, provided these are viable options in your scenario: - try to take advantage of caching. - if you create the same proxy types each time you run the application, create them once, and save the assembly to disk. On subsequent runs, load the proxy types from disk, so you don't take the performance hit. Also when choosing one, be it Castle, LinFu, Spring or any other, consider not only the time it takes to generate your proxies, but also other performance implications - memory footprint, runtime performance etc. I created a small benchmark for runtime performance some time ago: http://kozmic.pl/archive/0001/01/01/dynamic-proxy-frameworks-comparison-update.aspx You may find it useful. If you have any followup questions, please describe your scenario in more details on Castle group, and we'll see if there's anything we could do to improve it. cheers, Krzysztof srf wrote: > Well I finished running our integration tests and with linfu the tests > took 900 seconds and with castle it took 1800 seconds so there is > definatly some nasty stuff going on with castle . It all seems to be > just with the typebuilder and proxying since creating and saving is > the same with both proxies but the load tests take a big hit with the > castle proxy compared to linfu. So far I ran all our tests and > integration tests and application tests with linfu and all seems good > so Im hoping to go with that if nothing else comes up since the > performance hit in castle is just too much. This proxy plugin > architecture in nhibernate was quite the lifesaver. > > thanks > > scott > > On Aug 10, 9:37 am, Fabio Maulo <fabioma...@gmail.com> wrote: > >> Somebody pointed us to the same problem we the same solution in >> uNhAddIns.Personally >> I saw some difference, in production, in a stress-tests (usage of CPU) but >> I'm not completely sure that the problem was only LinFu DynamicProxy. >> The real problem of LinFu, IMO, is >> this:http://code.google.com/p/linfu/people/list >> >> <http://code.google.com/p/linfu/people/list>Try to think which is the >> problem. >> >> 2009/8/10 srf <scott.fl...@cmgl.ca> >> >> >> >> >> >> >> >> >>> Moving to nhibernate 2.1 from 1.2 I noticed a performance problem >>> doing proxying and I ended up noticing that castle dynamic proxy uses >>> the .net Type builder and the type build seems to have a bug where its >>> gets prgressivly slower the more types created. We have 300 different >>> types in our domain model and it would proxy 100 types pretty fast but >>> by the time it proxys the 200th type , the Type builder was taking >>> over 10 seconds to create a new type. We also run under mono and it >>> actually runs a lot faster since it doesnt have this same performance >>> problem. Maybe microsoft should see what the mono people are doing to >>> help with that. >>> At any rate, I switch to using LinFu and it had none of these >>> performance problems as was way faster and so far everything seems to >>> work so I was thinking of just switching our production environment to >>> use linfu but was wondering if others use linfu in production with >>> nhibernate and if anyone has had any problems with it? >>> >>> thanks >>> >>> scott >>> >> -- >> Fabio Maulo- Hide quoted text - >> >> - Show quoted text - >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
