4 ms·

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow) Could you elaborate on why they are so slow, compared to passing aro

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow) Could you elaborate on why they are so slow, compared to passing around/returning error objects explicitly?

pclmulqdq 4y ago
They are slow because you need to restore context from an unknown/unpredictable place in the code, you have a table lookup (from a very cold table) to get the next program counter value, and you have to save and restore register values, while the callstack and the calling convention handle all of that complexity for you if you don't break the natural flow of the program.
- codethief 4y ago
  But couldn't one implement exceptions internally by returning error codes? Yes, this would change the ABI but as long as we're not talking about the interface of a library, i.e. are not leaving the realms of our source code, this should be ok, shouldn't it? In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs. EDIT: I just realized my suggestion wouldn't exactly be equivalent to exceptions, in the sense that it wouldn't give stack traces but error return traces, like in Zig: https://ziglang.org/documentation/master/#Error-Return-Traces https://ziglang.org/documentation/master/#Error-Return-Trace...
  - codethief 4y ago
    > In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs. Here someone else had the same idea: https://news.ycombinator.com/item?id=34846550 https://news.ycombinator.com/item?id=34846550

4 ms·

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow) Could you elaborate on why they are so slow, compared to passing aro

by codethief 4y ago

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow) Could you elaborate on why they are so slow, compared to passing around/returning error objects explicitly?

pclmulqdq 4y ago
They are slow because you need to restore context from an unknown/unpredictable place in the code, you have a table lookup (from a very cold table) to get the next program counter value, and you have to save and restore register values, while the callstack and the calling convention handle all of that complexity for you if you don't break the natural flow of the program.
- codethief 4y ago
  But couldn't one implement exceptions internally by returning error codes? Yes, this would change the ABI but as long as we're not talking about the interface of a library, i.e. are not leaving the realms of our source code, this should be ok, shouldn't it? In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs. EDIT: I just realized my suggestion wouldn't exactly be equivalent to exceptions, in the sense that it wouldn't give stack traces but error return traces, like in Zig: https://ziglang.org/documentation/master/#Error-Return-Traces https://ziglang.org/documentation/master/#Error-Return-Trace...
  - codethief 4y ago
    > In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs. Here someone else had the same idea: https://news.ycombinator.com/item?id=34846550 https://news.ycombinator.com/item?id=34846550