geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Reflection performance
Date Mon, 01 Sep 2003 18:43:18 GMT
I spent a day last week testing the speed of reflective style 
invocations, and I found JDK reflection to be quite slow.  The good 
thing is this is not fatal.  First the overhead of an invocation should 
be small compared to the time spent in the method.  If it is not then 
the application is designed wrong, but if we could make people design 
good application life would be soooo much easier.

The good thing is there is another way to do reflection with out using 
JDK reflection.  The cglib project has a reflection replacement that is 
super fast.  Here are the results of the timings on my 1g powerbook:

Normal: 3.32 nanoseconds/invocation
Interface: 15.55 nanoseconds/invocation
Reflection: 358.1 nanoseconds/invocation
MethodProxy: 7.84 nanoseconds/invocation

The first line is a plain old straight invocation of an object.  The 
second line is the same invocation when the object is cast to an 
interface first, which means the vm must do a vtable look up.  The 
third invocation is a simple reflection invocation, and the last is a 
reflective invocation via a cglib MethodProxy.  Here is the chunk of 
code that does the MethodProxy test:

Method method = InvocationTarget.class.getMethod("invokeGetObject", 
int iterations = 100000000;
MethodProxy methodProxy = MethodProxy.create(method, method);
long time = System.currentTimeMillis();
for(int i=0; i<iterations; i++) {
     methodProxy.invoke(target, null);
time = System.currentTimeMillis() - time;
System.out.println("MethodProxy: " + time * 1000000.0 / iterations +
         " nanoseconds/invocation");

The cglib team also has a proxy generator that I would guess is equally 


On Monday, September 1, 2003, at 01:19 PM, Emmanuel Cecchet wrote:

> Hi,
> I just subscribed to the mailing list but I found in the archive some 
> discussion about performance. I am one of the author of the "EJB 
> performance and scalability" paper. I would like to precise that we 
> used OptimizeIt to profile cpu usage on running instances of JBoss 
> 2.4, JBoss 3.0 and JOnAS.
> In JBoss 2.4, we observed up to 34% of cpu time in reflection (using 
> JDK 1.3) and that was really limiting the scalability of the 
> container. When Sun announced a major improvement of reflection 
> scalability in JDK 1.4, we performed again the measurements since it 
> may have significantly affected the results. Finally, we just saw a 
> very little improvement of 2 to 4% that did not result in an overall 
> improvement.
> JBoss 3.0 has significantly reduced its usage of reflection (roughly 
> 1% of overall cpu time) which leads to much better performances.
> JOnAS has a precompiled approach and mostly doesn't use reflection 
> (0.1% of cpu time).
> In their stable releases, both JBoss 3.0 and JOnAS 2.6 performed 
> almost the same (and much better than JBoss 2.4). I don't have the 
> numbers for the latest versions since our measurements needs several 
> months to execute but the important point is that reflection induces a 
> performance scalability issue if you don't use it carefully. And JDK 
> 1.4 does not give a significant boost to reflection.
> I don't want to give any advice about container design but this was 
> our experience and I think it's important for the geronimo developers 
> to be aware of these facts.

View raw message