geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Reflection Bad, OO and direct Method invocation Good...
Date Sat, 09 Aug 2003 15:38:46 GMT
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