CODEWITHSUNDEEP
c++exceptiontry-catch
AJ S.
AJ S.

Reputation: 400

What is the performance overhead of try/catch blocks?

In general, I tend to use try/catch for code which has multiple failure points for which the failures have a common handler.

In my experience, this is typically code which qualifies input or context before performing some action or output after performing some action.

I have received counsel from literature and colleagues to minimize the code in such blocks and I accept that as generally good advice.

I would like to understand a bit more about the foundation for the above advice:

Upvotes: 16

Views: 13573

Answers (8)

Fred Larson
Fred Larson

Reputation: 62123

I found a technical report on C++ performance (pdf warning) that includes a section on exceptions. You might find it interesting. I've had coworkers who believed there was overhead on every instruction within a try/catch block, but this technical report doesn't seem to support that idea.

Upvotes: 7

Chris K
Chris K

Reputation: 12357

In C++ you shouldn't use try/catch blocks to perform cleanup. Instead, you might want to use templates to perform resource aquisition.

auto_ptr's are one [bad] example

Synchronization locks, where you store a mutex as a state variable, and use local variable (templates or regular classes) to perform the .acquire()/.release() methods.

The more of this you do, the less you have to worry about manually releasing objects in exceptional conditions. The C++ compiler will do it for you.

Upvotes: 0

Todd Gardner
Todd Gardner

Reputation: 13521

In c++, the cost depends on the implementation. In general, there are two ways to implement exceptions:

The first is the "table" approach. The compiler builds a set of tables to look up, at the point where the exception is thrown, where to go. When the exception is thrown, it has to search through each table up the call stack until it finds something that will catch this exception. Since this is all runtime based, entering or exiting a try catch produces no penalty (good) but throwing an exception involves potentially many lookups, producing a much slower throw. I personally prefer the not-having-to-pay for try catch blocks, because exceptions should be a very rare circumstance. This also would make executables larger, if they have to store the tables.

The seconds is the "code" approach. Each time the code enters a try catch block, conceptually, the location of the block is pushed onto a stack. This produces a cost during entering and exiting a try-catch block, however, when an exception is thrown, the runtime mechanism can quickly pop off the stack to find where to go. So, throwing exceptions is (much?) faster, but entering a block now has a cost. Putting a try catch block in a tight low level loop could produce significant overhead.

You would have to check your specific compiler to see which one they use.

Upvotes: 18

Jherico
Jherico

Reputation: 29240

I find the C++ FAQs site and corresponding book has an enlightening discussion on the matter.

http://www.parashift.com/c++-faq-lite/exceptions.html

Upvotes: 1

Nemanja Trifunovic
Nemanja Trifunovic

Reputation: 24559

Depends on a compiler. Why don't you write a simple function with a try-catch block and a similar one without it and compare the generated machine code?

Upvotes: 2

Douglas Leeder
Douglas Leeder

Reputation: 53285

In most languages entering and exiting a try/catch block via the normal methods is free, it's only when an exception is thrown that the exception handler looks up where to handle the exception.

Upvotes: 0

Nikolai Fetissov
Nikolai Fetissov

Reputation: 84239

To your second question: general guidelines are here, Herb Sutter also gives pretty good advise here.

Upvotes: 5

cmaxo
cmaxo

Reputation: 31

In my experience the biggest problem with try/catch blocks are we often try to catch exceptions too generically. For instance, if I wrap my main function with a try/catch block that catches (...) I am basically trying to not allow my program to crash b/c of a thrown exception.

The problem with this approach as I see it is two fold. 1) While I'm testing and debugging I don't see any errors and I don't get the opportunity to fix them. 2) It's really kind of taking the lazy way out. Instead of thinking through the problems that may come up and figuring out what the edge cases are I'm just trying not to fail. Trying not to fail is a lot different than trying to succeed.

Upvotes: 0

Related Questions