The collection thing was only an analogy. You missed the general point that
struts has fine performance for many applications as is, and it allows you
to create great/powerful/flexible/maintainable code. No one would deny that
there are cases where introspection might destroy performance, but in many
cases it is non-issue.
Furthermore, there have been articles and discussions on introspection
performance that indicate it is not nearly as bad performance wise as some
believe, though personally I remain a little skeptical about that.
David Corbin
----- Original Message -----
From: "Trieu, Danny" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 20, 2001 4:42 AM
Subject: RE: Suggestion: Enhance Struts perfrommance.....
> Craig,
>
> Thanks for you reply. I agree with all the points you said. My only
2cents
> was in the use of introspection that Struts used, and not the big spectrum
> of the Collection. Notice, The BeanInfo and the introspector hardly use
any
> Collection at all. May this is because of the late adoption of Collection
> that I am now aware of, but this is how I've got the idea from. Yes,
these
> issues became irrelavent when compare it to network latency and database
> response time.
>
> danny
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 19, 2001 11:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Suggestion: Enhance Struts perfrommance.....
>
>
> On Sun, 9 Sep 2001, Trieu, Danny wrote:
>
> > Date: Sun, 9 Sep 2001 14:46:17 -0700
> > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Suggestion: Enhance Struts perfrommance.....
> >
> > All,
> >
> > I am new to extending Struts. I alway know that Struts used
introspection
> > heavily to lookup bean info matching and calling bean properties. I was
> > extend some Struts' custom tags and attempted to look at the
> > Struts code and its utilities to learn how these tag being implemented.
I
> > found out that the author use Iterator a lot to iterate to a collection.
> My
> > only suggestion is that: If we know we have to iterate to the entire
> > Collection, wouldn't it be better if we just use array(..[]) to do just
> this
> > purpose instead of Iterator? We can alway convert a Collection to
array(
> > SomeType[] someTypeArray = someCollection.toArray(new SomeType[0]) ; )
> and
> > just loop through it. I think this would reduce a lot function call
over
> > head and improve perfrommance.
> >
> > My 2cents,
> >
> > --danny
> >
> > ps. Thanks
> >
> >
>
> Performance is always an interesting issue, because what works great in
> one application does not always work well in others. And, the relative
> cost of operations like object creation, garbage collection, and
> reflection depend *very* much on which JVM you are using.
>
> Struts follows the general programming principles laid down by the Java
> collections API. In particular, the size of a particular collection is
> unknowable (in the general case), and might even exceed your memory
> capacity (think of a List implementation that is backed by a
> ten-million-row database table :-).
>
> Let's consider the proposed case a little more carefully. We are really
> comparing these two approaches:
>
> Object items[] = findItems();
> for (i = 0; i < items.length; i++)
> doSomething(items[i]);
>
> Iterator items = findItemsIterator();
> while (items.hasNext())
> doSomething(items.next());
>
> Although the iterator based approach does involve more method calls
> (because of the hasNext() and next() methods), it has some crucial
> advantages:
>
> * You never need to create enough space to store the entire collection
> contiguously in memory in an array (if this is even feasible).
>
> * The iterator approach generates only one small piece of garbage
> when it is done (the Iterator instance itself). The array-based
> approach creates a large item (with lots of internal object references)
> which takes longer to garbage collect.
>
> * If you find out that you don't need the entire collection, you can
> stop processing an iterator. With an array, you have to generate
> the entire list no matter what.
>
> In practical terms, however, these issues are not usually relevant to the
> perceived response time in a web application -- response time is dominated
> by database and network latency. You should strive for clarity in your
> programming, because debugging and code maintenence is, in nearly every
> case, *much* more expensive than buying a little more CPU and memory.
>
> Craig
>
>
>
