geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John C. Dale" <>
Subject Re: Reflection Bad, OO and direct Method invocation Good...
Date Sat, 09 Aug 2003 15:08:35 GMT

Test Account wrote:

>    Reflection and dynamic proxies are a good thing in EJB containers.  To
>bear this out, deploy and ear file on JBoss.  Now deploy the same
>application on Orion/OC4J. Do this 1000s of times during development.
>Consider the time lost watching Orion complain and fail compiling generated
>classes.  Consider the time the development team loses waiting for this step
>to occur repeatedly even when the deployment is successful.  Now actually
>make a few requests on the application.  Do you notice any difference?
>    It seems that this issue may be related to the lazy loading development
>vs production deploy discussion in that a bifurcated deployment option *may*
>be of use.  Anyone care to write an production option alternative to
>reflection because they believe in the savings?  This is certainly something
>which can be done *should* it be demonstrable that reflection shows any
>degradation of performance in a working container.
Just one point on this.  Any difference between the two containers would 
never be noticed by a single human user/development.  It is under load, 
then thousands of potential concurrent users are dingin' the system that 
we really might want to start being more frugal with CPU.

Your points are well taken, though.

John C. Dale
Professional Services

>----- Original Message ----- 
>From: "Aaron Mulder" <>
>To: <>
>Sent: Saturday, August 09, 2003 9:38 AM
>Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>>On Sat, 9 Aug 2003, John C. Dale wrote:
>>>Microbenchmarks can in fact be misleading when we aren't talking about
>>>as much as a factor of 10!  Reflection, in the best case scenario below,
>>>was a factor of 10 slower!  The bottom line is that reflection takes a
>>>lot more electricity than does non-reflection.
>>No, really, it can be misleading by a factor of 10.  The compiler
>>or VM can "do things" (like inlining a method when you're testing the time
>>it takes to call different kinds of methods) that totally defeat a
>>microbenchmark.  I will certainly agree that "reflection is significantly
>>slower", but I don't think it's valuable to point to specific numbers on a
>>benchmark like you showed.
>>>You are absolutely right in that the round trip to the database is going
>>>to consume more time for the life of the user request than is a sequence
>>>of reflection-based calls.  That will always be the bottleneck in
>>>systems that don't have any kind of intelligent middle-tier cache - but
>>>wait, there's more!
>>>Entity EJBS are just that (a cache) aren't they?  Through intelligent
>>>caching and good design of our applications, we're able to avoid the
>>>extra knocks on the database if the entity of our type with our PK has
>>>already been loaded.  This, in my mind, is one of the chief advantages
>>>of using Entity Beans; throughput.  This throughput will definitely be
>>>impacted negatively if there are several reflection calls for each user
>>>request as the system comes under (and maintains) load.  Furthermore,
>>>although the bottleneck is clearly the round trip to the database for
>>>the hydration/storage of data, the time it takes to get to the point of
>>>JDBC query invocation will be effected negatively if reflection is used
>>>- this effect becomes more pronounced as the system comes under heavy
>>>load.  The sooner the JDBC query starts, the sooner it will finish.
>>In my experience, slow EJB apps can be attributed to the frequency
>>and nature of the JDBC calls and/or application problems far more often
>>than the server technology.  In other words, it's pretty rare to find an
>>EJB performance problem that can't be addressed without altering something
>>like whether the server uses reflection.  And in response to "the JDBC
>>request that starts faster finishes faster", granted, but I refer you to
>>my response to Frankie -- you won't notice any difference if every JDBC
>>request finishes 0.00002 seconds faster (and that's being generous).
>>>I would also note that 'optimizing away' performance issues due to
>>>reflection (assuming that the core of the system is based on reflection)
>>>is MUCH easier to type than it is to implement.  If we see the train
>>>coming now, why don't we get out of the
>>You're implicitly asserting that reflection has no advantage.
>>Agreed, if reflection has no advantage and costs performance, we should
>>avoid it.  I would argue that such is not the case, and the reflection
>> - is more straightforward/less buggy than generating custom Java code
>>during deployment (due to comments, exception handling, version control,
>> - is dramatically faster to start up then writing out Java code, running
>>the compiler, and reading the classes back in
>> - reduces the amount of code an EJB client is required to have access to
>>(1 server JAR and the code written by the EJB developer, instead of 1
>>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>>by the EJB developer)
>> - has less of an impact on debugging (vs. getting errors originating in
>>classes that the server generated)
>> - allows common code such as passing control to a chain of interceptors
>>to be written and compiled and tested in one place by a server developer,
>>instead of being generated into every method in every EJB
>> - gives the server developers more options for how to handle the passing
>>of requests over the network, and again lets that code be written once and
>>version controlled and so on rather than forcing us to maintain the code
>>that writes the code.
>>Well, that's what I can think of for now, and overall, I'd say
>>it's well worth a few microseconds on every request.

View raw message