Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does try-catch block decrease performance [duplicate]

This link states,

To catch exceptions we must place a portion of code under exception inspection. This is done by enclosing that portion of code in a try block. When an exceptional circumstance arises within that block, an exception is thrown that transfers the control to the exception handler. If no exception is thrown, the code continues normally and all handlers are ignored.

Does it mean that having a try block reduces performance due to the extra task of "inspection" during run time?

like image 342
bibbsey Avatar asked May 28 '13 05:05

bibbsey


People also ask

Does try catch impact performance?

In general, wrapping your Java code with try/catch blocks doesn't have a significant performance impact on your applications. Only when exceptions actually occur is there a negative performance impact, which is due to the lookup the JVM must perform to locate the proper handler for the exception.

Does try catch make code slower?

try catch block does not slow down your program at all and is basically a standard for catching exceptions. Try Catch statements is basically your safe net when it comes to bugs in your code/program.

What happens if we have multiple catch blocks?

Java Multi-catch block A try block can be followed by one or more catch blocks. Each catch block must contain a different exception handler. So, if you have to perform different tasks at the occurrence of different exceptions, use java multi-catch block.

Do try catch blocks hurt performance C++?

Does it mean that having a try block reduces performance due to the extra task of "inspection" during run time? Typically yes, but unless it's a time-critical, called-a-million-times, must-be-really-fast portion of code, I wouldn't base my decision of whether or not to use exceptions on this.


2 Answers

TL;DR NO, exceptions are usually faster on the non-exceptional path compared to error code handling.


Well, the obvious remark is compared to what ?

Compared to not handling the error, it obviously decrease performance; but is performance worth the lack of correctness ? I would argue it is not, so let us supposed that you meant compared to an error code checked with an if statement.

In this case, it depends. There are multiple mechanisms used to implement exceptions. Actually, they can be implemented with a mechanism so close to an if statement that they end up having the same cost (or slightly higher).

In C++ though, all major compilers (gcc introduced it in 4.x serie, MSVC uses it for 64 bits code) now use the Zero-Cost Exception Model. If you read this technical paper that Need4Sleep linked to, it is listed as the table-driven approach. The idea is that for each point of the program that may throw you register in a side-table some bits and pieces that will allow you to find the right catch clause. Honestly, it is a tad more complicated implementation-wise than the older strategies, however the Zero Cost name is derived by the fact that it is free should no exception be thrown. Contrast this to a branch misprediction on a CPU. On the other hand, when an exception is thrown, then the penalty is huge because the table is stored in a cold zone (so likely requires a round-trip to RAM or worse)... but exceptions are exceptional, right ?

To sum up, with modern C++ compilers exceptions are faster than error codes, at the cost of larger binaries (due to the static tables).


For the sake of exhaustiveness, there is a 3rd alternative: abortion. Instead of propagating an error via either status or exception, it is possible to abort the process instead. This is only suitable in a restricted number of situations, however it optimizes better than either alternative.

like image 68
Matthieu M. Avatar answered Sep 22 '22 18:09

Matthieu M.


Take a look at Section 5.4 of draft Technical Report on C++ Performance which is specifically about the overhead of try-catch statements in c++.

A little excerpt from the section:

5.4.1.1.2 Time Overhead of the “Code” Approach

• On entry to each try-block     ♦ Commit changes to variables enclosing the try-block     ♦ Stack the execution context      ♦ Stack the associated catch clauses  • On exit from each try-block     ♦ Remove the associated catch clauses      ♦ Remove the stacked execution context  • When calling regular functions      ♦ If a function has an exception-specification, register it for checking  • As local and temporary objects are created      ♦ Register each one with the current exception context as it is created  • On throw or re-throw      ♦ Locate the corresponding catch clause (if any) – this involves some runtime check (possibly resembling RTTI checks)      If found, then:      destroy the registered local objects      check the exception-specifications of the functions called in-between      use the associated execution context of the catch clause      Otherwise:      call the terminate_handler6 
like image 27
Syntactic Fructose Avatar answered Sep 22 '22 18:09

Syntactic Fructose