Why are you proxying the objects in the first place then? srf wrote: > I think I never ran accross the performance issue with linfu because > we redesigned it to no proxy our actual domain objects and created a > parallell set of objects that get proxied because even the best > interception times were still to slow for us and killed our simulator > since the simulator would do millions of method/property calls on the > domain objects. Our Reservior simulator simulating 5 years of oil > production went from 1 minute to 5 hrs to complete with it proxying > our domain objects. At any rate so far the performance times are the > same as they were before so its not slower or faster. I might look at > the type caching to fix the castle problem if linfu doesnt work out > anyhow. > > thanks > > scott > > On Aug 10, 1:13 pm, Krzysztof Koźmic <[email protected]> > wrote: > >> 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 >> thathttps://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx... >> 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-comparis... >> >> 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 <[email protected]> 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 <[email protected]> >>>> >>>>> 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 -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
