hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Iignatyev <kgignat...@yahoo.com>
Subject Re: Interceptor performance
Date Tue, 24 May 2005 18:26:37 GMT
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: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message