3 ms·

I've had major regressions in performance when a thrown exception was added. We narrowed it down to the fact that the compiler wasn't free to A) inline the fun

I've had major regressions in performance when a thrown exception was added. We narrowed it down to the fact that the compiler wasn't free to A) inline the function, B) reorder internal operations in the function which came before vs. after the exception being thrown.

gmueckl 7y ago
Yes, exceptions affect optimizations. The crux is that anything that might throw is a barrier to any other statement with observable side effects before or after it. Neither can be moved to the other side of the potential thrower. However, explicit error handling adds a branch and explicit return inatead of a potentially throwing statement, so if the compiler is rightfully pessimistic, no performance is lost. In the other hand, you can make the compiler ignore the potential for exceptions by declaring functions and methods nothrow. This will make the compiler ignore all considerations for potential exceptions in callers and lead to better optimizations in some cases. But sticking nothrow onto things is hard because when a nothrow fuction does happen to throw, you're in UB land.
- aw1621107 7y ago
  > because when a nothrow fuction does happen to throw, you're in UB land IIRC that was the originally proposed behavior for noexcept, but it was changed at some point to call std::terminate instead.
  - gmueckl 7y ago
    Yikes, of course it should be noexcept instead of nothrow in my previous post! However, I don't find any referenc to noexcept having gotten defined behaviour. Do you have any pointers?
    - aw1621107 7y ago
      In the current version of the standard on the GitHub repo [0], Section 14.5 Paragraph 5 says: > Whenever an exception is thrown and the search for a handler (14.4) encounters the outermost block of a function with a non-throwing exception specification, the function std::terminate is called (14.6.1). I don't know when precisely noexcept was changed to call std::terminate, but I did find N3103 (included in the 2010-08 post-Rapperswil mailing [1]), which argued that the standard should require calling std::terminate to avoid security issues. [0]: https://github.com/cplusplus/draft https://github.com/cplusplus/draft [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3103.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n310...

gmueckl 7y ago

Yes, exceptions affect optimizations. The crux is that anything that might throw is a barrier to any other statement with observable side effects before or after it. Neither can be moved to the other side of the potential thrower. However, explicit error handling adds a branch and explicit return inatead of a potentially throwing statement, so if the compiler is rightfully pessimistic, no performance is lost. In the other hand, you can make the compiler ignore the potential for exceptions by declaring functions and methods nothrow. This will make the compiler ignore all considerations for potential exceptions in callers and lead to better optimizations in some cases. But sticking nothrow onto things is hard because when a nothrow fuction does happen to throw, you're in UB land.

aw1621107 7y ago
> because when a nothrow fuction does happen to throw, you're in UB land IIRC that was the originally proposed behavior for noexcept, but it was changed at some point to call std::terminate instead.
- gmueckl 7y ago
  Yikes, of course it should be noexcept instead of nothrow in my previous post! However, I don't find any referenc to noexcept having gotten defined behaviour. Do you have any pointers?
  - aw1621107 7y ago
    In the current version of the standard on the GitHub repo [0], Section 14.5 Paragraph 5 says: > Whenever an exception is thrown and the search for a handler (14.4) encounters the outermost block of a function with a non-throwing exception specification, the function std::terminate is called (14.6.1). I don't know when precisely noexcept was changed to call std::terminate, but I did find N3103 (included in the 2010-08 post-Rapperswil mailing [1]), which argued that the standard should require calling std::terminate to avoid security issues. [0]: https://github.com/cplusplus/draft https://github.com/cplusplus/draft [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3103.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n310...