Throwing an exception in C++ involves scanning the stack frames and looking up each return address in some exception tables stored in the binary, then calling the handlers found in those tables. It is very expensive.
This is in contrast to early exception handling implementations in the 80s/90s that basically used setjmp/longjmp. Those made throwing cheaper, but at the expense of significant overhead for every “try” block entered, because all the CPU registers had to be copied to the stack.
It is interesting to me that this has been good starting-point advice for decades! I used to astonish new Java coders back in the 1.4 days by writing a quick benchmark demonstrating that exception handling was at least 1000x (and often far worse) the cost of a conditional.
Throwing an exception in C++ involves scanning the stack frames and looking up each return address in some exception tables stored in the binary, then calling the handlers found in those tables. It is very expensive.
This is in contrast to early exception handling implementations in the 80s/90s that basically used setjmp/longjmp. Those made throwing cheaper, but at the expense of significant overhead for every “try” block entered, because all the CPU registers had to be copied to the stack.
The impact is that if any particular call frame executes without an exception 99.999% of the time this “new” approach is faster.
Which is probably a good call. You service likely doesn’t have 99.999% success rate overall but for most individual stack frames it likely does.
I appreciate this comment thread over on the orange site: https://news.ycombinator.com/item?id=34089019
It is interesting to me that this has been good starting-point advice for decades! I used to astonish new Java coders back in the 1.4 days by writing a quick benchmark demonstrating that exception handling was at least 1000x (and often far worse) the cost of a conditional.