commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nokleberg <ch...@sixlegs.com>
Subject Re: [HiveMind] Interceptors - CGLIB / Javassist comparison
Date Sat, 06 Mar 2004 04:36:23 GMT
Harish Krishnaswamy wrote:
>> 2. Performance - This is interesting. CGLIB has a disadvantage here
>> due to the number of parameters passed to the intercept method. It
>> turns out, all of the overhead is because of these parameters that
>> cannot be overcome (atleast AFAIK). With a single counter interceptor
>> I could make Javassist as much as ~4 times as fast as CGLIB (~300%
>> faster). And with more interceptors obviously Javassist is more
>> faster. Now, if I insert a method call in the Javassist interceptor
>> with 4 parameters, to my surprise the performance is identical to the
>> CGLIB interceptor. Would be really nice if CGLIB can be designed
>> around this problem.

Yes, most of the overhead comes from both the method call to the interceptor
implementation and the creation of the argument array (Object[]).

In some cases (including probably your counter example), you can use a
different Callback type to avoid the argument overhead.

Removing the actual method call entirely is trickier. For one thing, you can
swap out the actual MethodInterceptor bound to a particular object at any
time (through the Factory interface). If this were disabled you could
potentially extract the bytecode of the MethodInterceptor and inline it
into the generated class, but to do this right requires some complicated
control flow analysis. Not impossible, but I haven't yet seen a use case
that demands this level of optimization--typically the cost of the
interceptor implementation itself will far outweigh the dispatching cost.

Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message