noexcept, stack unwinding and performance

The difference between noexcept and throw() is that in case of throw() the exception stack is still unwound and destructors are called, so implementation has to keep track of the stack (see 15.5.2 The std::unexpected() function in the standard).

On the contrary, std::terminate() does not require the stack to be unwound (15.5.1 states that it is implementation-defined whether or not the stack is unwound before std::terminate() is called).

GCC seem to really not unwind the stack for noexcept: Demo
While clang still unwinds: Demo

(You can comment f_noexcept() and uncomment f_emptythrow() in the demos to see that for throw() both GCC and clang unwind the stack)

There's "no" overhead and then there's no overhead. You can think of the compiler in different ways:

• It generates a program which performs certain actions.
• It generates a program satisfying certain constraints.

The TR says there's no overhead in the table-driven appraoch because no action needs to be taken as long as a throw doesn't occur. The non-exceptional execution path goes straight forward.

However, to make the tables work, the non-exceptional code still needs additional constraints. Each object needs to be fully initialized before any exception could lead to its destruction, limiting the reordering of instructions (e.g. from an inlined constructor) across potentially throwing calls. Likewise, an object must be completely destroyed before any possible subsequent exception.

Table-based unwinding only works with functions following the ABI calling conventions, with stack frames. Without the possibility of an exception, the compiler may have been free to ignore the ABI and omit the frame.

Space overhead, a.k.a. bloat, in the form of tables and separate exceptional code paths, might not affect execution time, but it can still affect time taken to download the program and load it into RAM.

It's all relative, but noexcept cuts the compiler some slack.