From: "Trieu, Danny" <[EMAIL PROTECTED]>
>
> Object construction is expensive as well.
One interesting data point on this topic was my own experience back in JDK
1.1 days (when I was building the internationalized webapp that created in
my mind the need for something like Struts :-).
In Sun JDK 1.1.8, object creation was indeed pretty expensive. But in the
IBM 1.1.8 JDK, running the very same program (gotta love that WORA :-), I
observed that object creation cost was well over an order of magnitude
(i.e. 10x) smaller. What I learned from this is that it was no longer
reasonable to make blanket statements about "slow" versus "fast" in Java,
without a reference to what JVM I'm talking about.
At the time of these experiments, I found that it was actually cheaper to
create objects rather than pool them, when running on the IBM JVM, even
taking into account the extra garbage collection activity. And this
mattered a lot, because we were running on a machine with 512mb allocated
to the JVM (so that we could massively cache stuff accessed from the
database).
Nowdays, the cost of object creation (and associated garbage collection)
in current Hotspot-based JVMs is pretty low. So low, in fact, that I no
longer "automatically" assume that object pooling will improve performance
-- it does sometimes, and doesn't sometimes. As a result, Struts 1.0
doesn't do any object pooling for the ActionForm objects it creates (the
only thing that is potentially created on a per-request basis).
For general scalability, I'm a firm believer in Moore's law -- "throw
hardware at it". (My current development platform has 512mb of memory and
40gb of disk -- my first "real" computer had *16kb* of memory and *10mb*
of disk, and cost 5 times as much, even discounting inflation :-).
It's a whole bunch cheaper than the developer time that can be spent
trying to over-optimize a software design.
That being said, the primary scalability story for large-scale Struts
based applications is to take advantage of the distributed processing
capabilities of modern J2EE application servers. As long as you obey the
constraints specified in the servlet spec (i.e. make your session
attributes Serializable), and in general minimize your use of session
attributes, you should be able to leverage your app server's capabilities
quite nicely.
Craig
