Does try...catch affects performance

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

  1. Efi Merdler

    Efi Merdler Guest

    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
    Efi Merdler, Mar 8, 2007
    #1
    1. Advertising

  2. Efi Merdler

    Guest

    On 8 Mar, 15:55, "Efi Merdler" <> wrote:
    > 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.
    , Mar 8, 2007
    #2
    1. Advertising

  3. Efi Merdler

    Efi Merdler Guest

    wrote:
    > On 8 Mar, 15:55, "Efi Merdler" <> wrote:
    > > 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

    >
    >But it would also of course depend
    > on how you want to catch any exception and what you want to do with it.


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

    Eric Sosman Guest

    Efi Merdler wrote On 03/08/07 11:40,:
    > wrote:
    >
    >>On 8 Mar, 15:55, "Efi Merdler" <> wrote:
    >>
    >>>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

    >>
    >>But it would also of course depend
    >>on how you want to catch any exception and what you want to do with it.

    >
    >
    > 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.

    --
    Eric Sosman, Mar 8, 2007
    #4
  5. Efi Merdler

    AmiDaniel Guest

    On Mar 8, 8:55 am, "Efi Merdler" <> wrote:
    > 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 ;).

    --
    Daniel Cannon
    AmiDaniel, Mar 8, 2007
    #5
  6. Efi Merdler

    Wojtek Guest

    AmiDaniel wrote :
    >
    > Btw, if your
    > ultimate concern is efficiency, you really shouldn't be coding in
    > Java ;).


    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."

    --
    Test Sig
    Wojtek, Mar 8, 2007
    #6
  7. On 08.03.2007 19:34, Wojtek wrote:
    > AmiDaniel wrote :
    >>
    >> Btw, if your
    >> ultimate concern is efficiency, you really shouldn't be coding in
    >> Java ;).

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

    Chris Uppal Guest

    Efi Merdler wrote:

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

    Mark Rafn Guest

    Efi Merdler <> wrote:
    [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.
    --
    Mark Rafn <http://www.dagon.net/>
    Mark Rafn, Mar 8, 2007
    #9
  10. Efi Merdler

    Lew Guest

    Eric Sosman wrote:
    > 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
    Lew, Mar 9, 2007
    #10
  11. Efi Merdler

    Guest


    > 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 ;)
    , Mar 9, 2007
    #11
  12. Efi Merdler

    Lew Guest

    wrote:
    > 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
    Lew, Mar 9, 2007
    #12
  13. Lew wrote:
    > wrote:
    >> 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

    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
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon Maz
    Replies:
    7
    Views:
    4,258
    Jon Maz
    Oct 25, 2004
  2. bienwell
    Replies:
    4
    Views:
    3,709
    bienwell
    May 27, 2005
  3. EnKan

    Re: try/catch performance

    EnKan, Aug 23, 2003, in forum: Java
    Replies:
    0
    Views:
    1,878
    EnKan
    Aug 23, 2003
  4. Stimp
    Replies:
    2
    Views:
    3,036
    Karl Seguin [MVP]
    Jun 23, 2006
  5. John Salerno
    Replies:
    20
    Views:
    819
    John Salerno
    Aug 11, 2006
Loading...

Share This Page