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:05:09 GMT
I have no problem with reflection for the instantiation of a policy 
*once* during the course of an applications' lifecycle.  However, using 
reflection rampantly for every user request will result in the vaunted 
and oft feared big Oh catastrophy.  If you have 1 + n reflection 
operations for every user request, the application performance relative 
to the reflection code will degrade exponentially with the increase of 
concurrent users to the system O(n exponential).

If its precise empirical data you're asking for, I would ask the same - 
99%?  ;)

The bottleneck is *always* at the database, which is constrained by the 
time it takes to shuttle bits-n-bytes back and forth from/to the 
database.  Software  optimization efforts at that level are wasted.  The 
nice thing, though, is that database technology has advanced to the 
extent that a 5ms query under no load doesn't degrade too fast under 
heavy user load - unlike reflection.

I have a feeling that many of the core developers on the team have 
already put an extensive amount of reflection into the system.  I have 
yet to see any code, but will be interested to do a performance 
evaluation on the existing kernel (if there is one :) .  Furthermore, 
I'm very interested in using probing utilities to discover the extent to 
which particular segments of code are slowing the system down.

How does an application 'not care if it is subject to reflection'? 
 Module isolation?  Low coupling?

I'll reiterate that a straight forward OO implementation will be easier 
to maintain than would something that relies heavily on being generic. 
 Usually, systems that are overly generic for the sake of saving 
development time spend far too much time developing a generic framework.



John C. Dale

Leo Simons wrote:

> John C. Dale wrote:
>> I'm concerned about your mention of reflection.  I really like 
>> reflection, and think it has many useful applications in the 
>> application development space, but should be kept out of any runtime 
>> application that has stringent scalability and performance requirements.
> it should be kept out of *any* code that has stringent performance 
> requirements.
> Indeed! One should know when to use the right tool.
> But in all applications I have ever developed using containers that 
> use reflection
> operations, (usually to do instantiation and facilitate late binding), 
> those operations
> have never turned out to be the bottleneck.
> 99% of time is spent doing I/O, waiting for locks, or doing actual 
> processing.
> If the development time gained by using some ingenious proxying or 
> reflection
> code you write once and use in the right place, is spent optimizing 
> the bottleneck
> code, your app becomes lighting fast.
> The trick is to write most of your application so that it does not 
> care whether
> it is subject to reflection of any kind at any point. If it turns out 
> that's your
> bottleneck, you can always take it out and replace it with something 
> efficient.
>> Here are some dramatic results:
> ehm. Why are they dramatic? Reflection is known to be slow, yes, but 
> I've yet
> to see hard figures showing it being the bottleneck in any realistic 
> system.
> cheers!
> - Leo

View raw message