Does try...catch affects performance

Discussion in 'Java' started by Efi Merdler, Mar 8, 2007.

  1. Efi Merdler

    Efi Merdler Guest

    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 (...) {

    Efi Merdler, Mar 8, 2007
    1. Advertisements

  2. Efi Merdler

    usenetuser Guest

    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.
    usenetuser, Mar 8, 2007
    1. Advertisements

  3. Efi Merdler

    Efi Merdler Guest

    Can you please explain ?
    Efi Merdler, Mar 8, 2007
  4. Efi Merdler

    Eric Sosman Guest

    Efi Merdler wrote On 03/08/07 11:40,:
    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);

    // 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);
    finally {

    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 Sosman, Mar 8, 2007
  5. Efi Merdler

    AmiDaniel Guest

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

    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 ;).
    AmiDaniel, Mar 8, 2007
  6. Efi Merdler

    Wojtek Guest

    AmiDaniel wrote :
    IBM seems to dis-agree with you:

    "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."
    Wojtek, Mar 8, 2007
  7. "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 Klemme, Mar 8, 2007
  8. Efi Merdler

    Chris Uppal Guest

    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
    Chris Uppal, Mar 8, 2007
  9. Efi Merdler

    Mark Rafn Guest

    [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
    Mark Rafn, Mar 8, 2007
  10. Efi Merdler

    Lew Guest

    .... snio ...

    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

    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

    -- Lew
    Lew, Mar 9, 2007
  11. Efi Merdler

    trstag75 Guest

    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"

    To be honest, on a second thought, it happens very often ;)
    trstag75, Mar 9, 2007
  12. Efi Merdler

    Lew Guest

    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
    Lew, Mar 9, 2007
  13. 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.
    Joshua Cranmer, Mar 10, 2007
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.