Aaron Mulder wrote:
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.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.
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 platform.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 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. hmmmm...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
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.
Best,
John C. Dale
Professional Services
Compuware
