Sandy,
The answer to 1) is no check needs to be made, because ArrayIndexOutOfBoundsException is a RuntimeException, and will be thrown by the VM if an incorrect subscript is referenced.
My comment to 2) (and the whole problem in general), (with the one caveat that I haven't read the exact code you are speaking about), is that I wouldn't "resize the array" -- ever. I am sure I don't know all the details, but I would use a static-sized array and manage its logical size (how many elements are actually used) via int variables. Then I would overwrite the array repeatedly when needed. Much faster performance, much gentler on memory.
BradO
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: a performance issue
Hi Tom & Brad,
Thanks for your reply. Though what you mentioned (loop iterations) is not
exactly the case I'm worrying, it definitely helps me understanding the
problem clearly.
Consider a method (from org.apache.xerces.utils.StringPool):
private boolean ensureCapacity(int chunk, int index) {
try {
return fOffset[chunk][index] == 0;
} catch (ArrayIndexOutOfBoundsException ex) {
// fOffset.length <= chunk || fOffset[chunk].length <= index
...
} catch (NullPointerException ex) {
// fOffset[chunk] == null
...
}
...
}
1. When the array is big enough, no exception will be thrown. Then whether
the following (a) is faster than (b)?
a. fOffset[chunk][index] == 0;
b. if (fOffset.length <= chunk || fOffset[chunk] == null ||
fOffset[chunk].length <= index)
(a) looks simpler, but doesn't it need to check the bounds to see whether
an exception should be thrown? And won't such check be similar to what's in
(b)? Let's ASSUME (a) is faster for now, and use "DIFF" to denote the time
difference between (a) and (b).
2. When we need to resize the array, then "throw-catch exception" is more
expensive than the above if statement (b).
So the question is (similar to loop iteration): is the number of case (1)
large enough to compromise the time spent in case (2)? That is, let
"ratio1" be (the number of case (1)) / (the number of case (2)), and let
"ratio2" be (the time spend on exception handling) / (DIFF), then whether
ratio1 > ratio2?
I ran a little test to get ratio1, and it appears to me (according to the
xml files I have) that it's roughly 60.
Could someone share some thoughts on how expensive exception handling is?
(checking bounds, creating object, throwing, catching, dispatching, ...) Is
it less than 60*DIFF? (DIFF should be very small, because (a) also needs to
check the bounds.)
Of course, there is a big chance that this "exception" approach is still a
better way, then I'd be happy to leave it and save some time for other
issues :-)
Thanks a lot,
Sandy Gao
Software Developer, IBM Canada
(1-416) 448-3255
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
