a performance issue

[sa...@ca.ibm.com]

Hi all,

In many classes, to detect the need of array-resizing, we try to access a
specific position, and do the resizing when
"ArrayIndexOutOfBoundsException" is caught (or NullPointerException for
multidimensional arrays).

But my understanding is that throw-catch exceptions is much more expensive
than get the array size directly: arrayVal.length. So there would be a big
performance hit if we resize arrays frequently. (In fact, we do resize
StringPool very often.)

So could anyone explain to me why it's designed this way?

Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-416) 448-3255
sandygao@ca.ibm.com


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: a performance issue

[Tom Bradford <br...@dbxmlgroup.com>]

sandygao@ca.ibm.com wrote:
> But my understanding is that throw-catch exceptions is much more expensive
> than get the array size directly: arrayVal.length. So there would be a big
> performance hit if we resize arrays frequently. (In fact, we do resize
> StringPool very often.)
> 
> So could anyone explain to me why it's designed this way?

While it's true that catching exceptions is more expensive than getting
an array size, performing comparisons for every iteration of a loop is
overall more expensive than the one time overhead of establishing a
catch block.  This will be especially true when the arrays start getting
very large.

-- 
Tom Bradford --- The dbXML Project --- http://www.dbxml.org/
We store your XML data a hell of a lot better than /dev/null

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: a performance issue

[Petr Kuzel <Pe...@sun.com>]

sandygao@ca.ibm.com wrote:
> 
> Hi all,
> 
> In many classes, to detect the need of array-resizing, we try to access a
> specific position, and do the resizing when
> "ArrayIndexOutOfBoundsException" is caught (or NullPointerException for
> multidimensional arrays).
> 
> But my understanding is that throw-catch exceptions is much more expensive
> than get the array size directly: arrayVal.length. So there would be a big
> performance hit if we resize arrays frequently. (In fact, we do resize
> StringPool very often.)

I understand throw-catch performance as unpredictable. Actual performance
depends on how deep a stack trace is. Filling the stack trace takes a lot of 
time. The deeper stack the more time is taken.

  Cc.

-- 
<address>
<a href="mailto:pkuzel@sun.com">Petr Kuzel</a>, Sun Microsystems
: <a href="http://www.sun.com/forte/ffj/ie/">Forte Tools</a>
: XML and <a href="http://jini.netbeans.org/">Jini</a> modules</address>

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: a performance issue

[Edwin Goei <ed...@sun.com>]

sandygao@ca.ibm.com wrote:
> 
> Hi all,
> 
> In many classes, to detect the need of array-resizing, we try to access a
> specific position, and do the resizing when
> "ArrayIndexOutOfBoundsException" is caught (or NullPointerException for
> multidimensional arrays).
> 
> But my understanding is that throw-catch exceptions is much more expensive
> than get the array size directly: arrayVal.length. So there would be a big
> performance hit if we resize arrays frequently. (In fact, we do resize
> StringPool very often.)

When measuring performance there are lots of variables that need to be
taken into account.  In particilar, in the case you mention, I believe
the JVM that you measure with can make a difference on which method is
faster.  My guess is that the code was tuned for a particular JVM in
which catching exceptions was faster, but that the JVM you measured with
has the opposite characteristic.  For example, I've seen a JVM where
certain Java exceptions where implemented using hardware trap
instructions on x86 architectures, so the code would run faster in that
case.  But, what eventually happens is that time passes and JVMs change
but not the code so the high level "performance tuning" is no longer
valid on newer JVMs so you end up with code that is difficult to
understand and may even perform worse compared to the straightforward
code.

So IMHO, the better approach to writing code like this would be to make
the code easily understandable and maintainable and let the JVM handle
the optimization.

-Edwin

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org