4 ms·

Exceptions are for exceptional events. If exceptions are effecting the performance of your application, you have done something horribly wrong.

by jpkst19 10y ago

scott_s 10y ago
My sentiment is a relative of yours: I care more about the performance of the two methods when there is no error, as that is the common path. Hopefully. In my own brief micro benchmarks, exceptions do have a performance penalty when there is no error. With that said, I still use them, but I sometimes have to think carefully about when.
- alfalfasprout 10y ago
  If you're seeing performance degradation as a result of including exceptions in your application the exceptions are generally not themselves to blame. The surrounding code can be a culprit. For instance, if you have a conditional that's not so easily predicted that in turn throws an exception then the cost comes not from the exception but from the branch misprediction. It all boils down to orders of magnitude. The overhead of a branch + exception is going to be a few cycles. That said, only in a really hot code path (eg; vectorized matrix operations) where I'm really pushing FLOPS then I'll avoid throwing exceptions. Realtime code is another place where avoiding exceptions is wise (since their cost is usually negligible but non-constant due to the exception frame). Otherwise, I have yet to see a benchmark that shows detrimental performance loss in all but the hottest loops.
  - scott_s 10y ago
    I work on (among other things) a soft-realtime streaming runtime where we care about microsecond latency, so I care about the cost of the common data path. You made a good point about the surrounding code being more simplistic making it more amenable to optimizations. But, I still see that as the "cost" of exceptions.
    - alfalfasprout 10y ago
      Yeah, I also work on systems where we care about microsecond latency (market data handling). In most cases, we still leave the exception handling in. It's maybe a few cycles of cost and we definitely need the whole system to stop if any of those exceptions come up. Then again, the costs are minimal b/c our conditional to check for an exception is easy to predict (simple comparison to a stack variable probably on the register already). In a hard realtime system you really have to move all the exception handling upstream and use error codes downstream. Problem is this does hurt performance in the average case.
alfalfasprout 10y ago
This is partly why I really want something like the expected monad to be accepted into the C++ standard: https://github.com/ptal/expected https://github.com/ptal/expected

Exceptions are for exceptional events. If exceptions are effecting the performance of your application, you have done something horribly wrong.

by jpkst19 10y ago

Exceptions are for exceptional events. If exceptions are effecting the performance of your application, you have done something horribly wrong.

scott_s 10y ago

My sentiment is a relative of yours: I care more about the performance of the two methods when there is no error, as that is the common path. Hopefully. In my own brief micro benchmarks, exceptions do have a performance penalty when there is no error. With that said, I still use them, but I sometimes have to think carefully about when.

alfalfasprout 10y ago
If you're seeing performance degradation as a result of including exceptions in your application the exceptions are generally not themselves to blame. The surrounding code can be a culprit. For instance, if you have a conditional that's not so easily predicted that in turn throws an exception then the cost comes not from the exception but from the branch misprediction. It all boils down to orders of magnitude. The overhead of a branch + exception is going to be a few cycles. That said, only in a really hot code path (eg; vectorized matrix operations) where I'm really pushing FLOPS then I'll avoid throwing exceptions. Realtime code is another place where avoiding exceptions is wise (since their cost is usually negligible but non-constant due to the exception frame). Otherwise, I have yet to see a benchmark that shows detrimental performance loss in all but the hottest loops.
- scott_s 10y ago
  I work on (among other things) a soft-realtime streaming runtime where we care about microsecond latency, so I care about the cost of the common data path. You made a good point about the surrounding code being more simplistic making it more amenable to optimizations. But, I still see that as the "cost" of exceptions.
  - alfalfasprout 10y ago
    Yeah, I also work on systems where we care about microsecond latency (market data handling). In most cases, we still leave the exception handling in. It's maybe a few cycles of cost and we definitely need the whole system to stop if any of those exceptions come up. Then again, the costs are minimal b/c our conditional to check for an exception is easy to predict (simple comparison to a stack variable probably on the register already). In a hard realtime system you really have to move all the exception handling upstream and use error codes downstream. Problem is this does hurt performance in the average case.

alfalfasprout 10y ago

This is partly why I really want something like the expected monad to be accepted into the C++ standard: https://github.com/ptal/expected https://github.com/ptal/expected