Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > how slow is exceptions really compared?

Reply
Thread Tools

how slow is exceptions really compared?

 
 
tom fredriksen
Guest
Posts: n/a
 
      02-16-2006

I was reading about exceptions and in the book "Effective Java" it is
stated that exceptions are terribly slow, about 79 times slower than the
FAST example below. Now i tested it and I cant see any difference. I
have heard this many times, but I am not sure how much I believe it. So
what is it that i so slow about exception. I understand that creating an
exception object is slow and sending it up the stack for processing at
every point is also slow. But as far as I can see that would only matter
if you used eceptions for flow control (i.e. for every iteration (for
some strange reason) or something similar). I dont see how it can be any
slower to use it as described in the SLOW code below (I know it is not
the correct way to do it, idiom wise). Any comments?

/tom

SLOW

try {
int i = 0;
while(true)
a[i++].f();
} catch(ArrayIndexOutOfBoundsException e) {
}


FAST:

for (int i = 0; i < a.length; i++)
a[i].f();
 
Reply With Quote
 
 
 
 
Timo Stamm
Guest
Posts: n/a
 
      02-17-2006
tom fredriksen schrieb:
>
> I was reading about exceptions and in the book "Effective Java" it is
> stated that exceptions are terribly slow


This has been true in early versions of java.


> But as far as I can see that would only matter
> if you used eceptions for flow control (i.e. for every iteration (for
> some strange reason) or something similar).


Exceptions are ment to handle exceptional control flow. Using them for
conventional flow control is bad design. So even if Exceptions were
still as slow as they have been five years ago, it should not not really
matter.


"Effective Java" doesn't seem to be a recommendable book.


Timo
 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      02-17-2006

"tom fredriksen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> I was reading about exceptions and in the book "Effective Java" it is
> stated that exceptions are terribly slow, about 79 times slower than the
> FAST example below. Now i tested it and I cant see any difference. I have
> heard this many times, but I am not sure how much I believe it. So what is
> it that i so slow about exception. I understand that creating an exception
> object is slow and sending it up the stack for processing at every point
> is also slow. But as far as I can see that would only matter if you used
> eceptions for flow control (i.e. for every iteration (for some strange
> reason) or something similar). I dont see how it can be any slower to use
> it as described in the SLOW code below (I know it is not the correct way
> to do it, idiom wise). Any comments?
>
> /tom
>
> SLOW
>
> try {
> int i = 0;
> while(true)
> a[i++].f();
> } catch(ArrayIndexOutOfBoundsException e) {
> }
>
>
> FAST:
>
> for (int i = 0; i < a.length; i++)
> a[i].f();


If you're timing the running of programs that do nothing but that code, you
won't see much difference, since the startup cost dwarfs everything else.

Try this test:

class Timing
{
public static void main(String[] args) throws Exception
{
int[] a = new int[10];

long start = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++)
{
try
{
int j = 0;
while(true)
{
a[j] = j;
j++;
}
}
catch(ArrayIndexOutOfBoundsException e)
{
}
}
System.out.println(
"Slow time is " + (System.currentTimeMillis() - start) +
" milliseconds.");

start = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++)
{
for (int j = 0; j < 10; j++)
{
a[j] = j;
}
}
System.out.println(
"Fast time is " + (System.currentTimeMillis() - start) +
" milliseconds.");
}
}

I get output like

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


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      02-17-2006

"Timo Stamm" <(E-Mail Removed)> wrote in message
news:43f5190e$0$13598$(E-Mail Removed)-online.net...

>
> "Effective Java" doesn't seem to be a recommendable book.


Are you kidding? It's one of the best Java books ever written. It's true
that it could stand updating, as some of the details are no longer accurate,
but overall it's check-full of good advice. In fact, the instructor at a
Microsoft course I once took called in the best C# book he knew of, because
so much of it is also applicable to .NET.


 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      02-17-2006
Mike Schilling schrieb:
> I get output like
>
> Slow time is 6843 milliseconds.
> Fast time is 63 milliseconds.



I get output like

Slow time is 65 milliseconds.
Fast time is 49 milliseconds.

(Run on a 4 processor 64 bit machine, so server vm is enabled by default
and the JIT kicks in.)


Micro-optimizations like using your own constructs instead of Exceptions
are a total waste of time. Even worse, they make the code difficult to
maintain.


Timo
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      02-17-2006

"Timo Stamm" <(E-Mail Removed)> wrote in message
news:43f5246d$0$13607$(E-Mail Removed)-online.net...
> Mike Schilling schrieb:
>> I get output like
>>
>> Slow time is 6843 milliseconds.
>> Fast time is 63 milliseconds.

>
>
> I get output like
>
> Slow time is 65 milliseconds.
> Fast time is 49 milliseconds.
>
> (Run on a 4 processor 64 bit machine, so server vm is enabled by default
> and the JIT kicks in.)
>
>
> Micro-optimizations like using your own constructs instead of Exceptions
> are a total waste of time. Even worse, they make the code difficult to
> maintain.


Using a for loop to navigate through an array is "my own construct" and a
"micro-optimization" that's "hard to maintain"? Good Lord.


 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      02-17-2006
Mike Schilling schrieb:
> "Timo Stamm" <(E-Mail Removed)> wrote in message
> news:43f5190e$0$13598$(E-Mail Removed)-online.net...
>
>> "Effective Java" doesn't seem to be a recommendable book.

>
> Are you kidding? It's one of the best Java books ever written.


I haven't read it, but what Tom reported sounded a lot like propagation
of micro-optimizations.


Timo
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      02-17-2006

"Timo Stamm" <(E-Mail Removed)> wrote in message
news:43f5272d$0$13593$(E-Mail Removed)-online.net...
> Mike Schilling schrieb:
>> "Timo Stamm" <(E-Mail Removed)> wrote in message
>> news:43f5190e$0$13598$(E-Mail Removed)-online.net...
>>
>>> "Effective Java" doesn't seem to be a recommendable book.

>>
>> Are you kidding? It's one of the best Java books ever written.

>
> I haven't read it, but what Tom reported sounded a lot like propagation of
> micro-optimizations.


Do you often judge books by second-hand reports of small sections of them?

Just asking.


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      02-17-2006
On Fri, 17 Feb 2006 00:41:13 +0100, tom fredriksen <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>Now i tested it and I cant see any difference.

The problem is compilers/JITs/AOTs are getting smarter. They easily
ultra- optimise contrived examples they could not tidy up in real
world situations.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      02-17-2006
Mike Schilling schrieb:
> "Timo Stamm" <(E-Mail Removed)> wrote in message
> news:43f5246d$0$13607$(E-Mail Removed)-online.net...
>> Mike Schilling schrieb:
>>> I get output like
>>>
>>> Slow time is 6843 milliseconds.
>>> Fast time is 63 milliseconds.

>>
>> I get output like
>>
>> Slow time is 65 milliseconds.
>> Fast time is 49 milliseconds.
>>
>> (Run on a 4 processor 64 bit machine, so server vm is enabled by default
>> and the JIT kicks in.)
>>
>>
>> Micro-optimizations like using your own constructs instead of Exceptions
>> are a total waste of time. Even worse, they make the code difficult to
>> maintain.

>
> Using a for loop to navigate through an array is "my own construct" and a
> "micro-optimization" that's "hard to maintain"?


Obviously not. Are you trolling? Here is an explanation for the interested:

A "micro-optimization" is a performance optimization at a low level. For
example, the following construct:

for( int i = upperbound; 0 != i--; ) {
// ...
}

is supposed to be more efficient than

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


This is actually true, the former construct can be more efficient in
statically compiled languages. But in a language like Java, which is
compiled into byte code and interpreted by a virtual machine that can
theoretically run on any platform, such optimizations don't make much
sense for several reasons:

The latter construct is standard - every programmer who knows languages
influenced by C will understand it at the first glance. Using your own
constructs will make the code harder to read for anybody else, which may
lead to more time-consuming maintenance and more bugs.

Additionally, you can not even be sure that this micro-optimization even
gained you any performance, because the Java VM has a just-in-time
compiler that works under the assumption that you wrote plain java code.
If this JIT compiler recognizes standard for loops and optimizes them,
you might even loose performance.

The same goes for assumptions about a lot of other constructs, about
memory management, etc.

Those optimizations have one thing in common: They are not made because
a programm runs too slow. They are premature. Donald Knuth said "We
should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil."

So you should never waste any time on optimization unless you have made
tests, clearly identified the bottleneck, and are able to change your
design accordingly. I am sure it will almost never be the for loop you
have to optimize.


Back to the original topic: Tom posted two variants of looping through
an array:


| SLOW
|
| try {
| int i = 0;
| while(true)
| a[i++].f();
| } catch(ArrayIndexOutOfBoundsException e) {
| }
|
|
| FAST:
|
| for (int i = 0; i < a.length; i++)
| a[i].f();


If this is taken from the book "Effective Java", I don't understand the
point the author is trying to make. The assumption that using Exceptions
this way is _much_ slower than the standard way is wrong. I see that the
book might be older than the JVM JIT Compiler, but this just proves that
you shouldn't make too much assumptions when you are writing for a JVM
whose implementation might change. (BTW: this is a very poor example for
JIT testing, because it will probably never appear in real world code.)

What really irritated is that there was no mention of any other argument
why the slow version is a bad idea other than that it is slower. I
consider the slow version to be a violation of the concept of exceptions
because they are used for standard control flow. This outweighs any
performance issues by far, imho.


| Do you often judge books by second-hand reports of small sections of
| them?
|
| Just asking.

I really didn't want to judge the book without having read it myself.
But it still doesn't seems to be worth trying out from what I have see
until now.

It isn't unlikely that this was all taken out of context, or that the
book has much better information to offer on other topics. If you have
any valuable information about the book to add, I would appreciate to
hear about it.


Tim
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: slow slow slow! Expert lino fitter Computer Support 5 12-12-2008 04:00 PM
Re: slow slow slow! Beauregard T. Shagnasty Computer Support 2 12-10-2008 09:03 PM
Re: slow slow slow! Expert lino fitter Computer Support 0 12-10-2008 02:33 PM
String#chop slow? REALLY slow? Mat Schaffer Ruby 11 07-27-2006 05:45 PM
Really slow, painfullu slow asp.net web app michael@randallk.com ASP .Net 3 02-15-2006 11:02 PM



Advertisments