Java Exceptions cause performance hit?

Discussion in 'Java' started by kk_oop@yahoo.com, Jul 13, 2005.

  1. Guest

    Hi. I wanted to use exceptions to handle error conditions in my code.
    I think doing that is useful, as it helps to separate "go" paths from
    error paths. However, a coding guideline has been presented that says
    "Use conventional error-handling techniques rather than exception
    handling for straightforward local error processing in which a program
    is easily able to deal with its own errors."

    By "conventional error-handling," I believe they mean returning an
    error code, or just handling the error without going to a catch block.


    When I said that I'd prefer throwing and catching exceptions--and that,
    in fact, exceptions is the "conventional error-handling technique" in
    Java, I was told that since we have a real-time system, we can't afford
    the performance hit caused by using exceptions.

    Do exception blocks cause big performance hits? If so, what causes the
    hit? Or is the person just misinformed?

    Thanks for any info,

    Ken
     
    , Jul 13, 2005
    #1
    1. Advertising

  2. On Wed, 13 Jul 2005 08:21:12 -0700, kk_oop wrote:

    > Do exception blocks cause big performance hits? If so, what causes the
    > hit? Or is the person just misinformed?


    I don't know how Java implements exception handling, but having
    done it in another language I would say that the only significant
    performance hit *should* be the construction of the stack trace
    (and even there one could argue about the definition of
    'significant'...). Plus, the ability of an thrown exception to
    perform a 'deep return' may help mitigate that cost.

    Personally, I think the benefit outweighs the cost, but I could
    understand someone (especially in a RT system) possibly wanting
    to cut that cost out - particularly if the stack trace could be
    turned on/off dynamically).

    One wonders, however, what Java version you're using in a
    real-time system...
     
    Steve Wampler, Jul 13, 2005
    #2
    1. Advertising

  3. Eric Sosman Guest

    wrote:
    > Hi. I wanted to use exceptions to handle error conditions in my code.
    > I think doing that is useful, as it helps to separate "go" paths from
    > error paths. However, a coding guideline has been presented that says
    > "Use conventional error-handling techniques rather than exception
    > handling for straightforward local error processing in which a program
    > is easily able to deal with its own errors."
    >
    > By "conventional error-handling," I believe they mean returning an
    > error code, or just handling the error without going to a catch block.
    >
    >
    > When I said that I'd prefer throwing and catching exceptions--and that,
    > in fact, exceptions is the "conventional error-handling technique" in
    > Java, I was told that since we have a real-time system, we can't afford
    > the performance hit caused by using exceptions.
    >
    > Do exception blocks cause big performance hits? If so, what causes the
    > hit? Or is the person just misinformed?


    Creating, throwing, catching, and eventually garbage-
    collecting a Throwable object is certainly a lot more work
    than a simple `if'. You can measure it for yourself by
    comparing the time required for two different ways of
    filling an array:

    for (int i = 0; i < array.length; ++i)
    array = i;

    try {
    for (int i = 0; ; ++i)
    array = i;
    } catch (ArrayIndexOutOfBoundsException ex) {}

    (This is pretty much the same experiment Joshua Bloch shows
    in "Effective Java.") On the machine I'm using at the moment,
    the exception-based approach takes 15.5 times as long as the
    straightforward loop to fill a 100-element array; that is, one
    exception takes longer than 1500 limit tests. Your machine
    may give different timings; try it and see.

    Note that the guidance you've been given does not forbid
    the use of exceptions; it only forbids them for "straightforward
    local error processing." I suggest you go back to the folks
    who wrote the guidelines and ask what "straightforward" means;
    it will probably turn out to be less burdensome than you seem
    to fear.

    --
     
    Eric Sosman, Jul 13, 2005
    #3
  4. wrote:

    > When I said that I'd prefer throwing and catching exceptions--and that,
    > in fact, exceptions is the "conventional error-handling technique" in
    > Java, I was told that since we have a real-time system, we can't afford
    > the performance hit caused by using exceptions.
    >
    > Do exception blocks cause big performance hits? If so, what causes the
    > hit? Or is the person just misinformed?
    >


    The problem with exceptions in hard real-time systems is that it
    introduces more invariants with respect to the expense of execution. It
    becomes more difficult to make guarantees about time and memory used, so
    I think that may be why it is preferred against when you can use
    something conventional in simpler cases.
    There may be some threshold of complexity where you opt for an exception
    over checking flags or error codes.
    There is a similar problem with garbage collection and making running
    time more predictable that RT implementations account for.
    --Paul
     
    Paul Bilnoski, Jul 13, 2005
    #4
  5. Eric Sosman wrote:

    > Note that the guidance you've been given does not forbid
    > the use of exceptions; it only forbids them for "straightforward
    > local error processing." I suggest you go back to the folks
    > who wrote the guidelines and ask what "straightforward" means;
    > it will probably turn out to be less burdensome than you seem
    > to fear.


    Good point.
    I was just wondering why worry about performance if an exception is for,
    well, exceptional cases. If an exception is being thrown so often to
    have a performance impact, either you have a problem with your code or
    you have a problem with your system.
    Maybe that person just wants to prevent exception abuse
     
    Andrea Desole, Jul 13, 2005
    #5
  6. Paul Bilnoski wrote:
    > wrote:
    >
    >> When I said that I'd prefer throwing and catching exceptions--and
    >> that, in fact, exceptions is the "conventional error-handling
    >> technique" in Java, I was told that since we have a real-time
    >> system, we can't afford the performance hit caused by using
    >> exceptions.
    >>
    >> Do exception blocks cause big performance hits? If so, what causes
    >> the hit? Or is the person just misinformed?


    A thrown exception causes the hit. IMHO the penalty in the normal case
    (no exception thrown) is neglectible.

    > The problem with exceptions in hard real-time systems is that it
    > introduces more invariants with respect to the expense of execution.
    > It becomes more difficult to make guarantees about time and memory
    > used, so I think that may be why it is preferred against when you can
    > use something conventional in simpler cases.
    > There may be some threshold of complexity where you opt for an
    > exception over checking flags or error codes.
    > There is a similar problem with garbage collection and making running
    > time more predictable that RT implementations account for.


    As far as I understand the term "real time system" I wonder why someone
    uses Java in the first place. There is no such thing as guaranteed
    response times etc. So maybe the OP is dealing with a soft real time
    system.

    http://en.wikipedia.org/wiki/Real-time_system

    Regards

    robert
     
    Robert Klemme, Jul 13, 2005
    #6
  7. Robert Klemme wrote:
    > Paul Bilnoski wrote:
    >
    >> wrote:
    >>
    >>
    >>>When I said that I'd prefer throwing and catching exceptions--and
    >>>that, in fact, exceptions is the "conventional error-handling
    >>>technique" in Java, I was told that since we have a real-time
    >>>system, we can't afford the performance hit caused by using
    >>>exceptions.
    >>>
    >>>Do exception blocks cause big performance hits? If so, what causes
    >>>the hit? Or is the person just misinformed?

    >
    >
    > A thrown exception causes the hit. IMHO the penalty in the normal case
    > (no exception thrown) is neglectible.
    >
    >
    >>The problem with exceptions in hard real-time systems is that it
    >>introduces more invariants with respect to the expense of execution.
    >>It becomes more difficult to make guarantees about time and memory
    >>used, so I think that may be why it is preferred against when you can
    >>use something conventional in simpler cases.
    >>There may be some threshold of complexity where you opt for an
    >>exception over checking flags or error codes.
    >>There is a similar problem with garbage collection and making running
    >>time more predictable that RT implementations account for.

    >
    >
    > As far as I understand the term "real time system" I wonder why someone
    > uses Java in the first place. There is no such thing as guaranteed
    > response times etc. So maybe the OP is dealing with a soft real time
    > system.
    >
    > http://en.wikipedia.org/wiki/Real-time_system
    >
    > Regards
    >
    > robert
    >


    I used Java for a few real-time system programming projects in college.
    We had a RT Linux kernel and the distributor also provided an RT Java VM
    implementation though it was not the full language (no 1.4 NIO, no Swing).
    There was also some extra functionality for the GC system to make it
    handle in a more predictable way.

    But to answer your point of "why use Java": because it is more
    comfortable to program multithreaded applications than with some C++
    threading libraries, among other things.
    --Paul
     
    Paul Bilnoski, Jul 13, 2005
    #7
  8. Exceptions have performance penalties when thrown, only minor when not
    thrown!
    Depending upon how you define "minor"!

    The challenge with exceptions is maintaining global state, like:
    - cursor state
    - timing state in real-time systems

    --
    Regards,
    Casey
     
    Casey Hawthorne, Jul 13, 2005
    #8
  9. Andrea Desole wrote:
    >
    >
    > Eric Sosman wrote:
    >
    >> Note that the guidance you've been given does not forbid
    >> the use of exceptions; it only forbids them for "straightforward
    >> local error processing." I suggest you go back to the folks
    >> who wrote the guidelines and ask what "straightforward" means;
    >> it will probably turn out to be less burdensome than you seem
    >> to fear.

    >
    >
    > Good point.
    > I was just wondering why worry about performance if an exception is for,
    > well, exceptional cases. If an exception is being thrown so often to
    > have a performance impact, either you have a problem with your code or
    > you have a problem with your system.
    > Maybe that person just wants to prevent exception abuse


    I haven't done any testing, so I speak in ignorance, but could it
    be that setting up the try/catch block is expensive? This will
    have to happen whether an Exception is actually thrown or not,
    and will therefore affect error-free performance too.

    The Cog
     
    Cantankerous Old Git, Jul 13, 2005
    #9
  10. Eric Sosman Guest

    Cantankerous Old Git wrote:
    > Andrea Desole wrote:
    >
    >>
    >>Eric Sosman wrote:
    >>
    >>
    >>> Note that the guidance you've been given does not forbid
    >>>the use of exceptions; it only forbids them for "straightforward
    >>>local error processing." I suggest you go back to the folks
    >>>who wrote the guidelines and ask what "straightforward" means;
    >>>it will probably turn out to be less burdensome than you seem
    >>>to fear.

    >>
    >>
    >>Good point.
    >>I was just wondering why worry about performance if an exception is for,
    >>well, exceptional cases. If an exception is being thrown so often to
    >>have a performance impact, either you have a problem with your code or
    >>you have a problem with your system.
    >>Maybe that person just wants to prevent exception abuse

    >
    >
    > I haven't done any testing, so I speak in ignorance, but could it
    > be that setting up the try/catch block is expensive? This will
    > have to happen whether an Exception is actually thrown or not,
    > and will therefore affect error-free performance too.


    Look at the bytecode, and you'll see that it's very
    cheap. The cost amounts to one unconditional jump at the
    end of the `try' clause to skip over the `catch' clause(s).
    It's possible that the JIT compiler might reorganize the
    compiled code to eliminate even that much overhead.

    --
     
    Eric Sosman, Jul 13, 2005
    #10
  11. Joan Guest

    <> wrote in message
    news:...
    > Hi. I wanted to use exceptions to handle error conditions in my code.
    > I think doing that is useful, as it helps to separate "go" paths from
    > error paths. However, a coding guideline has been presented that says
    > "Use conventional error-handling techniques rather than exception
    > handling for straightforward local error processing in which a program
    > is easily able to deal with its own errors."


    The key is "easily able to deal with its own errors." If it ain't easy, use
    toss/catch (if you want.)

    >
    > By "conventional error-handling," I believe they mean returning an
    > error code, or just handling the error without going to a catch block.
    >
    >
    > When I said that I'd prefer throwing and catching exceptions--and that,
    > in fact, exceptions is the "conventional error-handling technique" in
    > Java, I was told that since we have a real-time system, we can't afford
    > the performance hit caused by using exceptions.
    >
    > Do exception blocks cause big performance hits? If so, what causes the
    > hit? Or is the person just misinformed?
    >
    > Thanks for any info,
    >
    > Ken
    >
     
    Joan, Jul 13, 2005
    #11
  12. John Currier Guest

    Eric, your "performance comparison" is slightly skewed. The
    performance characteristics of the two approaches is highly dependent
    on the number of iterations and the cost of checking for the
    terminating condition. In your comparison the number of iterations
    (100) times the cost of checking (i < array.length) is extremely small
    compared to the cost of creating and throwing the exception. There are
    many scenarios where the opposite is true.

    John
    http://schemaspy.sourceforge.net
     
    John Currier, Jul 14, 2005
    #12
  13. Eric Sosman wrote:
    >
    > Look at the bytecode, and you'll see that it's very
    > cheap. The cost amounts to one unconditional jump at the
    > end of the `try' clause to skip over the `catch' clause(s).
    > It's possible that the JIT compiler might reorganize the
    > compiled code to eliminate even that much overhead.
    >

    I can imagine.
    I think that the impact on the performance is basically due to two factors:

    1) exception construction (specially the stack, I believe)
    2) search for an appropriate exception handler (you have to go through
    the entire stack until you find one)
     
    Andrea Desole, Jul 14, 2005
    #13
  14. Andrea Desole wrote:

    > I think that the impact on the performance is basically due to two factors:
    >
    > 1) exception construction (specially the stack, I believe)


    Yes, construction of the stack trace is rather expensive.

    <http://java.sun.com/j2se/1.5.0/relnotes.html#hotspot>

    The compiler in the server VM now provides correct stack backtraces for
    all "cold" built-in exceptions. For performance purposes, when such an
    exception is thrown a few times, the method may be recompiled. After
    recompilation, the compiler may choose a faster tactic using
    preallocated exceptions that do not provide a stack trace. To disable
    completely the use of preallocated exceptions, use this new flag:
    -XX:-OmitStackTraceInFastThrow.


    > 2) search for an appropriate exception handler
    > (you have to go through the entire stack until you find one)


    Once the exception has been constructed
    unrolling of the stack (and executing finally blocks)
    should perform not much different from
    unrolling of the stack due to return statements.
     
    Thomas Schodt, Jul 14, 2005
    #14
  15. Thomas Schodt wrote:
    >
    >> 2) search for an appropriate exception handler (you have to go through
    >> the entire stack until you find one)

    >
    >
    > Once the exception has been constructed
    > unrolling of the stack (and executing finally blocks)
    > should perform not much different from
    > unrolling of the stack due to return statements.


    Well, what I mean is that, while you are unwinding the stack and
    executing finally blocks, you also have to check, at every stack frame,
    if there is a catch block able to handle the exception.
    But maybe you are right anyway: it shouldn't be a big difference.
     
    Andrea Desole, Jul 14, 2005
    #15
  16. Ken Guest

    Thomas Schodt wrote:
    > Andrea Desole wrote:
    >
    > > I think that the impact on the performance is basically due to two factors:
    > >
    > > 1) exception construction (specially the stack, I believe)

    >
    > Yes, construction of the stack trace is rather expensive.
    >


    Is this price paid at run time only when an exception is actually
    thrown? Or does simply having a try/catch block or a throw statement
    in the java code cause this to happen at run time even when an
    exception is not thrown?

    Thanks!

    Ken
     
    Ken, Jul 14, 2005
    #16
  17. Ken wrote:
    >
    > Is this price paid at run time only when an exception is actually
    > thrown? Or does simply having a try/catch block or a throw statement
    > in the java code cause this to happen at run time even when an
    > exception is not thrown?


    when the exception is not thrown is not constructed, so there is no problem
     
    Andrea Desole, Jul 14, 2005
    #17
  18. On Thu, 14 Jul 2005 13:29:20 +0200, Andrea Desole wrote:

    >
    >
    > Thomas Schodt wrote:
    >>
    >>> 2) search for an appropriate exception handler (you have to go through
    >>> the entire stack until you find one)

    >>
    >>
    >> Once the exception has been constructed
    >> unrolling of the stack (and executing finally blocks)
    >> should perform not much different from
    >> unrolling of the stack due to return statements.

    >
    > Well, what I mean is that, while you are unwinding the stack and
    > executing finally blocks, you also have to check, at every stack frame,
    > if there is a catch block able to handle the exception.
    > But maybe you are right anyway: it shouldn't be a big difference.


    Gaak. I hope the JVM doesn't unroll the stack. It should be
    using a simple (internal) hash map to 'jump' directly to the
    correct catch clause. Yes, that adds a small bit to each
    try block to adjust the hash map, but most of the work
    for it can be done at translation time.
     
    Steve Wampler, Jul 14, 2005
    #18
  19. On Thu, 14 Jul 2005 07:28:02 -0700, Steve Wampler wrote:


    > ...I hope the JVM doesn't unroll the stack.


    Oops, I meant "unwind", not unroll. Of course the stack is
    rolled back to some previous point, but shouldn't be an
    unwinding process.
     
    Steve Wampler, Jul 14, 2005
    #19
  20. On Thu, 14 Jul 2005 07:28:02 -0700, Steve Wampler wrote:

    > Gaak. I hope the JVM doesn't unroll the stack.


    Sigh. Ignore me. I forgot about those finally blocks,
    which force some unwinding...
     
    Steve Wampler, Jul 14, 2005
    #20
    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. Jasper
    Replies:
    1
    Views:
    454
    Joe Smith
    Jun 27, 2004
  2. Jeremy

    Performance hit on ASP.NET

    Jeremy, Jul 9, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    366
    Jeremy
    Jul 9, 2003
  3. CK
    Replies:
    9
    Views:
    410
    Jerry Rasmussen
    Oct 19, 2006
  4. Replies:
    59
    Views:
    1,631
    Gene Bushuyev
    Jul 28, 2005
  5. Replies:
    3
    Views:
    621
    Sherm Pendley
    Apr 16, 2007
Loading...

Share This Page