Konstantin, Did you have a particular reason why you did not have your Hivemind ServiceInterceptorFactory.createInterceptor() method return a CGLIB proxy instead of a JDK proxy?
I believe you would have found that Hivemind interceptors would have performed very close to your home grown CGLIB solution. It is important to remember that Hivemind is technology agnostic with regards to interceptors. I have used JDK, CGLIB, and Javassist proxies depending on what I need. Since I discovered CGLIB, I normally have my ServiceInterceptorFactory.createInterceptor() method return a CGLIB proxy because of the reasons you documented, i.e. CGLIB proxies are easy, and fast. BTW, thanks for the article, Richard -----Original Message----- From: Konstantin Iignatyev [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 11:27 AM To: [email protected] Subject: Re: Interceptor performance Michael Mattox wrote: >>Some time ago I compared interceptors performance, HM >>is not bad: >>http://kgionline.com/articles/aop_1/aop_perf.jsp >> >> > >Your page was very interesting, thanks. > You are welcome. > I was suprised at the performance >results, I didn't expect them to be that bad. I remember when I was >playing with AspectWerkz 1.x almost a year ago, I remember them claiming >the performance hit was around 10%. I was thinking 10% I can live with. >But the other day when I read 50% for JDK proxies I became concerned. >When I see your performance results, for HiveMind the difference is 22x >slower with the interceptor! > It is not that bad. See, HiveMind is just 4 times slower than CGLib based interceptor, and CGLib seems to be fastest. IMO that particular performance degradation is not big deal if used in few places ( usually layer boundaries), but may cause problems if AOP system used unwisely. >Now what's interesting is that someone else >pointed out that when measured with real code the difference in perf won't >be noticeable. I'm not so sure about that. > Well, Hibernate seems to work just fine and I do not hear many complaints about its performance (it uses CGLib, in fact that is exactly why I started exploring CGLib and ended up using my little CGLib based class enhancer). Tapestry works OK too ( uses Javassist). JBoss-AOP (Javassist) is slightly faster than HM, but less convenient to use IMO. >Here's what I'm looking at: >My client would like the ability to add a cache to services and would like >this cache to be transparent. So I'm looking at the HiveMind interceptors >to make a cache interceptor that can be applied to any service. It's a >good idea, but if it slows down the performance 50% then I think we will >have performance problems. > Performance will degrade only if getting the data again takes less time than interceptor imposed delay. >The site is a very high profile site (lots of >activity). So I'm debating if we should continue with this cache >interceptor approach and then measure the perf and if it's too slow then >we deal with it later (for example make the cache non-transparent), or if >we should just abandon the cache interceptor now. > Well, you may try using build-time interceptors with XDoclet code generator. I initially used the approach but then abandoned it in favor of CGLib. >Normally I prefer to >deal with performance problems when they arise but this one seems very >high risk so I think it merits at least a small prototype, which I'll >probably need to do anyway in order to learn more about HiveMind. > > Wise plan. >Regards, >Michael > > -- Thanks, Konstantin Ignatyev http://www.kgionline.com PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
