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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
