cglib performance continued

The main problem with it seems to be proxy creation performance. Invoking methods through a cglib proxy looks a lot faster than with a jdk proxy but creating a cglib proxy is 8x the cost of creating a jdk proxy and the jdk proxy is a lot slower than simply newing an object up (which would approximate an aspect approach).

This creation problem seems the only remaining problem with it when compared with an aspect approach. I popped a question to the cglib dev list this morning so we'll see what turns up.

If this is the way it is then pooling proxies could help but the EJB 3.0 spec forbids that as a performance option as the proxies can be used by the application after commit so that looks a non-starter.

anyway, onwards....

Comments

[Julien Dubois]

Hi Billy,

I've blogged recently about the same subject (http://www.jroller.com/page/julien.dubois/), and I agree with you.

That's why CGLIB is only interesting if you use it with singletons or pooled objects. One more reason to use Spring, IMHO.

[Jonas]

You should try out AW Proxy (in AspectWerkz), same as cglib but a lot faster runtime perf. We optionally pool the proxies as well...

[Alex]

For our AWProxy bench refer to http://docs.codehaus.org/display/AW/AOP+Benchmark

In short this give you a proxy based component with an underlying aspect based programming model for writing the interceptors and such.
AspectJ/Spring integration will move toward that as well.

For EJB 3 in particular, you may want to look at my prototype that bridge AOP and EJB 3 interceptors together for maximal feature / performance vs implementation time benefits.

http://blogs.codehaus.org/people/avasseur/archives/001002_ejb_3_and_aop_the_ejb_interceptor_dilemna.html