geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert McIntosh <>
Subject Re: Reflection Bad, OO and direct Method invocation Good...
Date Sun, 10 Aug 2003 06:41:24 GMT
I have to agree partially with Craig here. I would venture to say that 
most of those many thousand users of JBoss use it for development where 
they do not have to run a separate compiler (actually a code generator), 
compile again, then package yet again and deploy. I agree that dynamic 
proxies will be slower, but that doesn't mean that a class generator at 
runtime couldn't take the place of that proxy. As a developer, I should 
be able to take my EJBs, compiled once I might add, package and drop 
into some deploy directory and let the container take it from there. It 
is a massive time saver during development.


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.
>----- 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