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 14:28:35 GMT

Aaron Mulder wrote:

>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.
So we're in agreement then that reflection is slower, regardless of the 
benchmark's presence in my argument.  I always like to have some 
supporting empirical evidence - a habit, really...but as long as we're 
in agreement on that point.

>>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).
And let's not forget the people writing the SQL - you are right IMHO, 
but with one additional qualification.  The SQL that is being executed 
is far more often the culprite than is the JDBC implementation.  In my 
experience, I've found that stable releases of most JDBC drivers are 
very nice.  So much revolves around the application design (the web/EJB 
app, not the container) and implementation, and we are *all* in 
agreement that bad developers write bad apps no matter how fast/good the 

>>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.
I have yet to see the code, so I am happy to suspend judgement regarding 
the advantage point until I get the opportunity to get a really critical 
look at the implementation you have in mind.  Coincidentally, you made 
the point very well and also suggest an alternative that hasn't worked 
in the past.  It's almost as though you've argued this issue before. 

Thanks for taking the time to make your points, and they are well taken. 
 I will be watching the implementation closely and will be happy to 
reverse-engineer documentation and do some performance probing to reduce 
the risk(s) of embedding significant amounts of (hopefully isolated) 
reflection into the kernel.


John C. Dale
Professional Services


View raw message