Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: general questions about try - catch

James Bucanek <email@hidden> wrote:

> [...a nice test-case...]
>Iterations=10000, call depth=10, returning Objects,
>execution time=15ms (1ns average)
>Iterations=10000, call depth=20, returning Objects,
>execution time=19ms (1ns average)
>Iterations=10000, call depth=30, returning Objects,
>execution time=25ms (2ns average)
>
>Iterations=10000, call depth=10, throwing Exceptions,
>execution time=487ms (48ns average)
>Iterations=10000, call depth=20, throwing Exceptions,
>execution time=653ms (65ns average)
>Iterations=10000, call depth=30, throwing Exceptions,
>execution time=812ms (81ns average)

OK, now you've piqued my curiosity, so...

I changed the code to either throw a new DeepException, or create a new
DeepException and simply return it. This changes the time-difference from
a factor or 30-40 down to well under a factor of 2 (about 1.5X). That is,
creating a new DeepException and returning it is only about 1.5X faster
than creating a new DeepException and throwing it.

Conclusion: instantiating the Exception takes much of the time. This is
understandable, given that creating an Exception requires filling in the
stack back-trace, with line-numbers if a line-number table is present. It
also explains why there's a roughly linear relationship between stack-depth
and speed of exception creation.

And yes, it takes somewhat longer with line-numbers than without, but the
percentage isn't much.


Then I changed the code again, so there's only one instance of
DeepException that's thrown and rethrown, vs. many instances of Integer
that are returned. In the test, I created the DeepException instance in
the constructor:
private DeepException rethrown = new DeepException( 0 );

I then throw the same instance every time:
if (testExceptions)
throw rethrown;

This changes the time-difference down to a factor of 10. That is, it's
about 10X faster to create and return an Integer than it is to throw the
'rethrown' exception. And it's about 3X-4X faster to rethrow the same
exception than it is to create and throw a new one every time. Obviously,
catching a rethrown exception will not see the actual stack-trace, but that
might be OK.

In particular, if all you're doing is signalling a particular condition,
then the stack-trace is pointless since it's never used. The fact that
rethrowing the same exception is 3X-4X faster than throwing a new one every
time might affect your decision of whether to use try/catch/finally or
returned objects. It depends on what you're signalling, how often, and
what the other cost/benefits are (try/catch/finally clarity,
maintainability, conditionals).

The difference between throwing 'rethrown' and simply returning it is about
15X. So even though an Integer is simpler than an exception to construct,
it's still faster if you don't have to construct anything at all.


There is some variation in relative speed between MRJ 2.2.5 on a 604e vs.
Java 1.3.1 on a G4. The relative differences tend to hold, though, or at
least the relative merits of each approach. I suspect that there are also
relative speed variations among different platforms and different JVM
versions, so measuring what you actually do on the platforms you actually
run on is the only way to understand real performance. But then, it always
is.

BTW, milliseconds divided by 1000 yields microseconds (us), not nanoseconds
(ns).

Thanks for the insightful test-case.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.