Does try...catch affects performance

E

Efi Merdler

Hello,
Let's assume I have the following code:

try {
line = file.readLine();
} catch (IOException e) {
....
}
.... // code
try {
line = file.readLine();
} catch (IOException e) {
....
}

does this type of code is faster then trying to include everything
under try, i.e.
try {
line = file.readLine();
.... // code
line = file.readLine();
} catch (IOException e) {
....
}

What happens when I'm using a loop, that is
for (...) {
try {
....
} catch (...) {
}

Thanks,
Efi
 
U

usenetuser

Hello,
Let's assume I have the following code:

try {
line = file.readLine();} catch (IOException e) {
...
}

... // code
try {
line = file.readLine();

} catch (IOException e) {
...
}

does this type of code is faster then trying to include everything
under try, i.e.
try {
line = file.readLine();
... // code
line = file.readLine();

} catch (IOException e) {
...
}

What happens when I'm using a loop, that is
for (...) {
try {
...

} catch (...) {
}

Thanks,
Efi

Run it through a profiler and see! But it would also of course depend
on how you want to catch any exception and what you want to do with it.
 
E

Eric Sosman

Efi Merdler wrote On 03/08/07 11:40,:
Can you please explain ?

You might want to handle the same exception differently
at different points in the code. For example,

// Open the file:
try {
file = new FileReader(path);
} catch (IOException ex) {
System.err.println("Can't access " + path);
System.err.println(ex);
return;
}

// Okay, we got the file. Now process it:
Transaction t = new Transaction();
try {
// read the file and perform the Transaction
} catch (IOException ex) {
System.err.println("Error reading " + path);
System.err.println(x);
t.cancel();
}
finally {
file.close();
}

That is, your response to an error that occurs before things
get fully started may differ from your response to errors
later on. Using two catch clauses -- hence two try blocks --
is a natural way to express the differences.
 
A

AmiDaniel

Hello,
Let's assume I have the following code:

try {
line = file.readLine();} catch (IOException e) {
...
}

... // code
try {
line = file.readLine();

} catch (IOException e) {
...
}

does this type of code is faster then trying to include everything
under try, i.e.
try {
line = file.readLine();
... // code
line = file.readLine();

} catch (IOException e) {
...
}

What happens when I'm using a loop, that is
for (...) {
try {
...

} catch (...) {
}

Thanks,
Efi

I highly doubt you're going to get considerably more performance
either way, but you can time them and see. Probably the fastest would
be:

try {
for (...) { ... }
catch (IOException e) { ... }

But I doubt even that would make a measurable difference. Btw, if your
ultimate concern is efficiency, you really shouldn't be coding in
Java ;).
 
R

Robert Klemme

AmiDaniel wrote :

IBM seems to dis-agree with you:
http://www.research.ibm.com/compsci/project_spotlight/plansoft/index.html

"The dynamic nature of the Java language provides opportunities for
better optimization based on runtime profile information, and this is a
significant advantage of a Java dynamic compiler over a traditional
static compiler."

"Java is slow" is a myth. Period.

Apart from that: there are many ways to interpret "efficiency" - another
team at our company spent considerable amounts of time in searching for
memory leaks on a regular basis - they do C++. ;-)

Kind regards

robert
 
C

Chris Uppal

Efi said:
does this type of code is faster then trying to include everything
under try, i.e. [...]

It implementation dependent, but you can safely assume that entering a
try/catch block has no direct cost at runtime (it's different, of course, if an
exception is actually thrown).

There may be an small indirect cost, because use of try/catch blocks may
affect optimisation in the JIT a little, but that's nothing to worry about for
normal code (and probably not for most abnormal code either).

-- chris
 
M

Mark Rafn

[regarding whether multiple try/catch blocks are faster or slower than one
block containing multiple statements]

1) It's probably very slightly faster to have fewer try/catch blocks. I'd
expect this to be unmeasurable in most apps and irrelevant even if you can
measure it.

2) It doesn't matter which is faster - THEY'RE FUNCTIONALLY DIFFERENT! It's
like asking "is it faster to add one to an int or set it to 0. It doesn't
matter which is faster - you should do what's correct for your program.

try { op1(); } catch (Exception e) { /* do something */ }
try { op1(); } catch (Exception e) { /* do something */ }
is _NOT_ necessarily the same as
try { op1(); op1(); } catch (Exception e) { /* do something */ }

If you're returning (or breaking from the loop) inside the catch block,
they're equivalent, but then performance still isn't the guiding factor.
Avoiding repeated code and confusing flow leads you to the second usage
naturally.
 
L

Lew

Eric said:
You might want to handle the same exception differently
at different points in the code. For example,
.... snio ...
That is, your response to an error that occurs before things
get fully started may differ from your response to errors
later on. Using two catch clauses -- hence two try blocks --
is a natural way to express the differences.


Eric points to a very important principle here - do what's right, not what you
(usually incorrectly) guess is fast.

Using a code idiom because you think it's faster is almost always wrong in
desktop or enterprise application coding. (It's right in real-time
applications, but doing that properly requires an even deeper understanding of
when and how not to optimize.) Use the code idiom that instructs the computer
to do the right actions. Speed isn't very helpful in a useless or erroneous
system.

So if logging IOExceptions differently according to when or where they happen
will help keep a production system working correctly, go ahead and use
separate catch blocks. Ignore whether it's faster or slower; it makes no
difference.

-- Lew
 
T

trstag75

But I doubt even that would make a measurable difference. Btw, if your
ultimate concern is efficiency, you really shouldn't be coding in
Java ;).

Posting that to c.l.j.p. is close to trolling...

How comes Java is backing, say, GMail, eBay and Voca (Voca
is processing real money, in the real world, in the UK, where about
80 millions payments *per day* are processed using Java)?

In my experience Java is only slow when sloppy programmers that
do not know/understand the language use its APIs in very dumb
ways, then blame the slowness on Java being an "inefficient"
language...

To be honest, on a second thought, it happens very often ;)
 
L

Lew

In my experience Java is only slow when sloppy programmers that
do not know/understand the language use its APIs in very dumb
ways, then blame the slowness on Java being an "inefficient"
language...

To be honest, on a second thought, it happens very often ;)

Not just with Java, either.

Even in 1999 Java was very fast - I worked on an application that parsed long,
complex EDI (Electronic Data Interchange) documents into a database over a
network connection. Java was never slower than the I/O. Our program handled up
to roughly 250K documents per hour. The secret was a single-pass algorithm
that wove through callbacks and created database transactions as it went.

Algorithms trump language every time. I have seen fast code written in BASIC
and slow code in C.

-- Lew
 
J

Joshua Cranmer

Lew said:
Not just with Java, either.

Even in 1999 Java was very fast - I worked on an application that parsed
long, complex EDI (Electronic Data Interchange) documents into a
database over a network connection. Java was never slower than the I/O.
Our program handled up to roughly 250K documents per hour. The secret
was a single-pass algorithm that wove through callbacks and created
database transactions as it went.

Algorithms trump language every time. I have seen fast code written in
BASIC and slow code in C.

-- Lew
The biggest "slowness" of Java is in the virtual machine startup (~200
ms, important iff your code is expected to run in under 200 ms). Other
than that, it can approach native speeds and generally seems to run (to
me at least) ~ 1.5 times as slow (not counting GUI, IO blocking, etc.):
definitely the best interpreted language I've used.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top