Re: Nhibernate-development Digest, Vol 28, Issue 8
"Ayende Rahien" <[email protected]> Thu, 4 Sep 2008 07:32:10 -0400
| Newsgroups | gmane.comp.windows.dotnet.nhibernate.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0846994566== Content-Type: multipart/alternative; boundary="----=_Part_22471_28937759.1220527930620" ------=_Part_22471_28937759.1220527930620 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The Dynamic Proxy implementation is caching types already internally. On Thu, Sep 4, 2008 at 4:33 AM, Andrew Mayorov <[email protected]> wrote: > Johan, > > I agree about ability to make a choice. BTW, we use NH in web environment, > so a little bigger delay in startup doesn't matter. For us it's more > important to be able to add new types w/o recompilation of all package, so > precompiled proxies doesn't seem as good solution. > > Anyway, I think that stock implementation of proxy generator should be > modified in a way you've described - it should cache types. There are very > little efforts necessary for this, while bonus is obvious. > > Best, > Andrew > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf > > Of Johan Kirsten > > Sent: Thursday, September 04, 2008 12:09 PM > > To: [email protected] > > Subject: Re: [NHibernate-development] Nhibernate-development Digest, > > Vol 28, Issue 8 > > > > Hi Andrew > > > > Unfortunately the theory is different from the practice. I have > > investigated > > this matter > > (http://groups.google.com/group/nhibernate- > > development/browse_thread/thread/90b9e4feca7c3552) > > > > Basically the problem is that NHibernate compiles the proxy each time > > and > > every time it needs to instantiate the proxy. i.e for each constructor > > call > > there is a preceding compilation of the proxy. It does not get cached. > > Please refer to the class > > NHibernate.Proxy.Poco.Castle.CastleProxyFactory. > > > > Your options are: > > 1) change NHibernate.Proxy.Poco.Castle.CastleProxyFactory to cache its > > proxy > > type as in the link above > > 2) use compile time proxies. > > > > If option 1 is used, then your theory is correct. I prefer to use > > compile > > time proxies as I want my users not to have unnecessary delays. The > > more I > > can move to compile time or start up the better. I tried to move the > > compilation of all my run time proxies to startup by altering > > NHibernate.Proxy.Poco.Castle.CastleProxyFactory, but that took too long > > and > > used a lot of memory. I have a complicated system with a lot of types. > > Hence > > I prefer compile time proxies. Other people might prefer option 1. I > > think > > people should be given a choice. > > > > Best regards > > > > Johan Kirsten > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Thu, 4 Sep 2008 11:39:24 +0400 > > > From: "Andrew Mayorov" <[email protected]> > > > Subject: Re: [NHibernate-development] Speed improvement using compile > > > time generated proxies > > > To: "'the NHibernate development list'" > > > <[email protected]> > > > Message-ID: <037101c90e61$5dae9970$190bcc50$@com> > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Hi! > > > > > > > > > > > > Guys, can anyone explain why precompiled proxy could be faster than > > > runtime > > > generated in real application? Proxy generation should be one time > > > operation > > > for each type, and as soon as we've made a proxy for particular type > > there > > > should be no difference in method of its creation. Yes, first query > > with > > > precompiled proxy would execute faster, but all subsequent should > > have the > > > same speed. > > > > > > > > > > > > Best, > > > > > > Andrew > > > > > > > > > > > > > > ----------------------------------------------------------------------- > > -- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Nhibernate-development mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/nhibernate-development > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Nhibernate-development mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/nhibernate-development > ------=_Part_22471_28937759.1220527930620 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr">The Dynamic Proxy implementation is caching types already internally.<br><br><div class="gmail_quote">On Thu, Sep 4, 2008 at 4:33 AM, Andrew Mayorov <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Johan,<br> <br> I agree about ability to make a choice. BTW, we use NH in web environment,<br> so a little bigger delay in startup doesn't matter. For us it's more<br> important to be able to add new types w/o recompilation of all package, so<br> precompiled proxies doesn't seem as good solution.<br> <br> Anyway, I think that stock implementation of proxy generator should be<br> modified in a way you've described - it should cache types. There are very<br> little efforts necessary for this, while bonus is obvious.<br> <br> Best,<br> <font color="#888888">Andrew<br> </font><div><div></div><div class="Wj3C7c"><br> > -----Original Message-----<br> > From: <a href="mailto:[email protected]">[email protected]</a><br> > [mailto:<a href="mailto:[email protected]">[email protected]</a>] On Behalf<br> > Of Johan Kirsten<br> > Sent: Thursday, September 04, 2008 12:09 PM<br> > To: <a href="mailto:[email protected]">[email protected]</a><br> > Subject: Re: [NHibernate-development] Nhibernate-development Digest,<br> > Vol 28, Issue 8<br> ><br> > Hi Andrew<br> ><br> > Unfortunately the theory is different from the practice. I have<br> > investigated<br> > this matter<br> > (<a href="http://groups.google.com/group/nhibernate-" target="_blank">http://groups.google.com/group/nhibernate-</a><br> > development/browse_thread/thread/90b9e4feca7c3552)<br> ><br> > Basically the problem is that NHibernate compiles the proxy each time<br> > and<br> > every time it needs to instantiate the proxy. i.e for each constructor<br> > call<br> > there is a preceding compilation of the proxy. It does not get cached.<br> > Please refer to the class<br> > NHibernate.Proxy.Poco.Castle.CastleProxyFactory.<br> ><br> > Your options are:<br> > 1) change NHibernate.Proxy.Poco.Castle.CastleProxyFactory to cache its<br> > proxy<br> > type as in the link above<br> > 2) use compile time proxies.<br> ><br> > If option 1 is used, then your theory is correct. I prefer to use<br> > compile<br> > time proxies as I want my users not to have unnecessary delays. The<br> > more I<br> > can move to compile time or start up the better. I tried to move the<br> > compilation of all my run time proxies to startup by altering<br> > NHibernate.Proxy.Poco.Castle.CastleProxyFactory, but that took too long<br> > and<br> > used a lot of memory. I have a complicated system with a lot of types.<br> > Hence<br> > I prefer compile time proxies. Other people might prefer option 1. I<br> > think<br> > people should be given a choice.<br> ><br> > Best regards<br> ><br> > Johan Kirsten<br> ><br> > > ------------------------------<br> > ><br> > > Message: 2<br> > > Date: Thu, 4 Sep 2008 11:39:24 +0400<br> > > From: "Andrew Mayorov" <<a href="mailto:[email protected]">[email protected]</a>><br> > > Subject: Re: [NHibernate-development] Speed improvement using compile<br> > > time generated proxies<br> > > To: "'the NHibernate development list'"<br> > > <<a href="mailto:[email protected]">[email protected]</a>><br> > > Message-ID: <037101c90e61$5dae9970$190bcc50$@com><br> > > Content-Type: text/plain; charset="us-ascii"<br> > ><br> > > Hi!<br> > ><br> > ><br> > ><br> > > Guys, can anyone explain why precompiled proxy could be faster than<br> > > runtime<br> > > generated in real application? Proxy generation should be one time<br> > > operation<br> > > for each type, and as soon as we've made a proxy for particular type<br> > there<br> > > should be no difference in method of its creation. Yes, first query<br> > with<br> > > precompiled proxy would execute faster, but all subsequent should<br> > have the<br> > > same speed.<br> > ><br> > ><br> > ><br> > > Best,<br> > ><br> > > Andrew<br> > ><br> > ><br> ><br> ><br> ><br> > -----------------------------------------------------------------------<br> > --<br> > This SF.Net email is sponsored by the Moblin Your Move Developer's<br> > challenge<br> > Build the coolest Linux based applications with Moblin SDK & win great<br> > prizes<br> > Grand prize is a trip for two to an Open Source event anywhere in the<br> > world<br> > <a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br> > _______________________________________________<br> > Nhibernate-development mailing list<br> > <a href="mailto:[email protected]">[email protected]</a><br> > <a href="https://lists.sourceforge.net/lists/listinfo/nhibernate-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/nhibernate-development</a><br> <br> <br> -------------------------------------------------------------------------<br> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<br> Build the coolest Linux based applications with Moblin SDK & win great prizes<br> Grand prize is a trip for two to an Open Source event anywhere in the world<br> <a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br> _______________________________________________<br> Nhibernate-development mailing list<br> <a href="mailto:[email protected]">[email protected]</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/nhibernate-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/nhibernate-development</a><br> </div></div></blockquote></div><br></div> ------=_Part_22471_28937759.1220527930620-- --===============0846994566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ --===============0846994566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nhibernate-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nhibernate-development --===============0846994566==--