geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@coredevelopers.net>
Subject Re: Reflection performance
Date Mon, 01 Sep 2003 21:13:50 GMT
What is cglib?

--jason


On Tuesday, September 2, 2003, at 01:43  AM, Dain Sundstrom wrote:

> 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", 
> null);
> 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 fast.
>
> -dain
>
> 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.
>>
>


Mime
View raw message