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 way...now?
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
code:
- is more straightforward/less buggy than generating custom Java code
during deployment (due to comments, exception handling, version control,
etc.)
- 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.
Aaron
