I don’t understand either how the compiler can suffer a performance hit when using it, but I don’t try to grasp the complexities of compilers, maybe related to the existing zero-cost abstraction for exceptions (they are free in terms of performance except when they actually throw) so +1 for benchmarking.
But even ignoring this performance issue, and after reading for a while about the topic, I don’t think flagging everything as noexcept is a good idea.
Exceptions are about handling the recovery, noexcept is nothing else than saying, don’t try to recover from whatever exceptional behavior that might occur in this function. But most of the cases… you don’t care if the compiler tried to unwind everything and then terminate because uncaught exception, or directly terminate without the unwinding (when noexcept is specified).
The big gain then is not in machine code, it is in the standards established in algorithms, and those standards say that if you have a noexcept move assignment, and/or a noexcept swap they will be used instead of copying, with big algorithmic optimizations as @LucH pointed out.
These algorithmic optimizations require noexcept in:
- move constructor and assignment.
- swap
- memory deallocators
- destructors (noexcept by default since c++11)
It is hard to think about exceptions, so I agree that it is good idea to limit the use to the cases where it really matters. Of course, I am talking generally, there must be low-level functions that are worth to specify as noexcept as well for development reasons.