You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Trieu, Danny" <DT...@ebuilt.com> on 2001/09/09 23:46:17 UTC

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


Re: Suggestion: Enhance Struts perfrommance.....

Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 9 Sep 2001, Trieu, Danny wrote:

> Date: Sun, 9 Sep 2001 14:46:17 -0700
> From: "Trieu, Danny" <DT...@ebuilt.com>
> Reply-To: struts-user@jakarta.apache.org
> To: struts-user@jakarta.apache.org
> 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