Chris Nokleberg wrote:
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.
Yes, I tend to agree. I should try some real use cases and see how they compare. Thanks!
-Harish
Chris
--------------------------------------------------------------------- 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]
