On Thu, 9 Aug 2001, Kevin McLain wrote:
> The only thing I would add to your argument is the fact that Struts relies
> fairly heavily on Reflection to set attributes on beans. Since Reflection
> incurs a much higher overhead than a straight method call (although I have
> heard that JDK 1.4 improves this performance considerably) - I did a rough
> test and found that this could be as much as three times as long - it could
> become a scalability issue as well...
>
Even if 3x is an accurate statistic (seems high based on my experience
with JDK 1.3.1, especially when making repeated calls on the same bean
class where the caching Struts does helps you out), the key question is,
does it matter? If you run out of database access speed or network
bandwidth first, for example, reflection that cost 100x the CPU of a
direct call would still have zero effect on response time and the number
of users you can support.
Scalability requires knocking down (or working around) bottlenecks as you
run into them. If this one happens to be the one you hit first, it's
feasible to throw some more CPU at it (and trade the hardware cost for the
developer cost of having to "avoid" the use of reflection). In most cases
I've seen, though, CPU does not tend to be the gating resource.
Craig
