how slow is exceptions really compared?

[Timo Stamm]

This is exactly the point that Bloch is making in Effective Java. The
two examples come from "Item 39: Use exceptions only for exceptional
conditions" and the first is preceeded by the comment "Horrible abuse of
exceptions. Don't ever do this!". The discussion of performance is
just a rebuttal of the argument that using exceptions in this way would
be quicker by avoiding termination test for each iteration of the loop.

Thanks Daniel, it makes a lot more sense now.

I agree with Mike's assessment of the book. And it's not just the two
of us, it is widely regarded as the best book ever written on Java
programming.

Maybe it's time to update my bookshelf.


Timo

 

[Chris Uppal]

I get output like

Slow time is 6843 milliseconds.
Fast time is 63 milliseconds.

Just a couple of extra observations.

One is that (as Timo has mentioned) the -server optimisations (JDK 1.5.0) are
capable of almost eliminating the difference -- I find that quite surprising.
(I rejigged the code a little to ensure that the test wasn't being optimised
away).

Secondly I tried plugging ever larger[*] arrays into the code, but was unable
to find a point where the "slow" code caught up with the "fast" code (for
either -server or -client). The relative difference declined dramatically, of
course, but never went away entirely. Which suggests that the explicit bounds
test is completely compiled away and/or is being wrapped into the JVM's own
bounds checking (by the JITer or the chip).

([*] Up to 10M byte[] array)

-- chris

 

[Daniel Dyer]

Maybe it's time to update my bookshelf.

It might be worth waiting for a couple of months, there is a second
edition of Effective Java scheduled for around the time of this year's
JavaOne.

Dan.

 

[Mike Schilling]

Obviously not. Are you trolling?

No, I'm quoting you.

 

[Mike Schilling]

If seen the former variant quite often in JDK source code (eg BitSet
implementation of and), but don't understand why this should be faster.
Both do the same number of instructions, with the difference of adding and
substraction. Can you explain why the first one is better to optimize, or
just give me a web-page explaining this?

Do you see this much with upperbound being a constant or a simple variable?
If it's a more complex expression, you can see why, for example,

for( int i = list.size(); --i>=0; ) {
// ...
}

might be faster than

for( int i = 0; i < list.size(); i++ ) {
// ...
}

 

[Mike Schilling]

It might be worth waiting for a couple of months, there is a second
edition of Effective Java scheduled for around the time of this year's
JavaOne.

Very cool. Thanks for the heads up.

 

[Roedy Green]

public static void f1(int[] a) {
for (int i=1000000; 0 != i--
for (int j=9; 0 <= j; --j)
a[j] = j;
}

You have to be very careful with this sort of benchmark. What you may
actually be measuring in the ability of the compiler to optimise your
peculiar case test code away so it does nothing at all. See
http://mindprod.com/jgloss/benchmark.html

You have to do real work the compiler can't slither out of, while at
the same time not adding so much overhead you disturb what you are
trying to measure.

What would really turn my crank in a 32-bit Periscope. In the old
16-bit days I could hit a hardware plunger that generated a
non-maskable interrupt, and then I could stop a program at that very
instant and see the assembler code it was running. I could single step
it if I wanted, or set breakpoints, all much like running Eclipse
debugger, but at the machine code level.

It was very useful for finding out what code was up to at times it was
irritating you.

Of course back then, except for the OS, I wrote every line of code
myself, so I knew my way around the assembler. Today, most of the code
is somebody else's and hence far more mysterious.

With such a tool, I could be sure HotSpot had not pulled a sneaky
trick that would not apply in a real world situation.

I still keep and wear my Periscope tee shirt, torn though it is as a
sort of homage to a great departed tool.

 

[Roedy Green]

Fair enough, i thought I had written a statement like that a couple of
days ago, but that was all in my mind.

Do you still write C, or dream in FORTRAN?

I have so many computer dreams about furiously coding all night and
wake up to discover it was all blithering nonsense.

I contemplate the possibility the Buddhists are right and eventually I
will awake from this reality to discover it was all blithering
nonsense too. Global politics and the reaction of humanity to various
environmental crises make it feel like a ludicrous dream, just as my
dreams sometimes hint with their silliness they are not real.

 

[Roedy Green]

Just a couple of extra observations.

Since Hotspot runs interpretively for a while, then mildly optimised,
the with server exhaustively optimised, it depend on when and how long
you time what sort of result you get.

we are usually interested in the final state. So let the benchmark
code "warm up" for a while before you start measuring it. What a
"while" is, I don't know. I suspect need to call the method the code
is in many times to kick in the optimisation.

 

[Chris Uppal]

Roedy Green wrote:

we are usually interested in the final state. So let the benchmark
code "warm up" for a while before you start measuring it. What a
"while" is, I don't know. I suspect need to call the method the code
is in many times to kick in the optimisation.

I put micro-benchmarks in a callable method, and then invoke them in a
loop. Often infinite.

-- chris

 

[Stefan Ram]

I put micro-benchmarks in a callable method, and then invoke
them in a loop. Often infinite.

For an attempt, albeit imperfect, to build a small framework
for this purposes see »TimeThese1« in:

http://www.purl.org/stefan_ram/pub/timethese-in-java

 

[tom fredriksen]

Do you still write C, or dream in FORTRAN?

I have so many computer dreams about furiously coding all night and
wake up to discover it was all blithering nonsense.

I contemplate the possibility the Buddhists are right and eventually I
will awake from this reality to discover it was all blithering
nonsense too. Global politics and the reaction of humanity to various
environmental crises make it feel like a ludicrous dream, just as my
dreams sometimes hint with their silliness they are not real.

There is no need to that! Its an honest mistake. I am sure you have done
one or two in your lifetime as well.

/tom