Zero-overhead deterministic exceptions: Throwing values //Herb Sutter
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r2.pdf

위 제안서는, try-catch 문법을 유지하면서, 구현은 error return code를 이용하는 exception 처리 모델을 제안하는데,
이때의 단점을 최적화라고 얘기하면서 이의 해결을 위해, error code리턴으로 구현하지 않고 보통의 table-based로 구현할지를
컴파일 옵션을 통해 선택하는 것도 제안한다:
pg.22
At call sites (that propagate or handle an error), a potential downside of the if-error-goto-handler implementation model
is that it injects branches that can interfere with optimizations. However, because this static exception model is
isomorphic to error codes (which the dynamic exception model is not), implementations can also choose
whether to implement this exception model as error returns or using table-based handling as a pure optimization
(no longer a required overhead).
And this was tried out in practice in a large native code system on the Midori project, which used a very similar exception design:
“A nice accident of our model [an the exception model that was isomorphic to error codes]
was that we could have compiled it with either return codes or [table-based] exceptions.
Thanks to this, we actually did the experiment, to see what the impact was to our system’s size and speed.
The exception[-table]s-based system ended up
being roughly 7% smaller and 4% faster on some key benchmarks.” — [Duffy 2015]

또 이러한 시도는 이미 이전의 다른 프로젝트에서 "in practice in a large native code system"에 있었음을 명시하면서,
table-based로 구현 했을 때 4% 속도 향상 결과를 인용하고 있다.
table-based는 현재 g++,clang, visual c++이 사용하고 있는 보통의 exception 처리 구현 방법이다.
개인적 실험에서는, g++,clang에서: 테스트 코드와 컴파일러(g++/clang), 컴파일 옵션(-O2,-O3)에 따라 들쑥날쑥하지만
전체적으론 거의 비슷하거나 exception이 약간 빨랐던거 같고,
visual c++에서는: 일관되고 확연하게(보통 3,4배이상 ~10배까지) exception이 return code보다 빨랐다.
exception처리 속도를 잴때 exception을 던져서 잡는 속도를 재면 안된다. exception처리 능력이 있는 코드에서 exception이 발생하지 않는 성공 path의 처리 속도를 재야한다.

어떤 인간은 c++ exception이 setjmp 보다도 느리다고 하는데, 현재의 table-based가 사용되기 전엔, g++에선 sjlj방식이, vitual c++에선 seh방식이 사용되었다. sjlj는 setjmp-longjmp의 약칭이다. 기본적으로, 필요한 몇개 register를 복구하고 jmp하는 식은 seh와 현재의 table-based도 같다. setjmp는 필요도 없는 거의 모든 register를 보관하기 때문에 overhead가 크다. 또한 최소한으로 구현하더라도, caller들쪽에 정의된 catch문들을 탐색하기 위해 jmp buffer들을 서로 연결해야 하는데 추가적 overhead가 발생한다. table-based방식은 jmp buffer연결의 overhead가 없다
; 이때도 마찬가지로 longjmp되지 않는, 에러 없는 정상적 path의 속도를 비교해야 한다.


C++ 표준에, exception 대안들이 제안되는 것을 보고, 현재의 exception방식이, 모든 경우에 exception을 버리고 그 대안들을 써야할 만큼 잘못된 것이라는 게 컨센서스라는 생각을 가진 인간들이 있는거 같은데, 전혀 그렇지 않다.
위 문서 pg.13에 명시된 Ideal error handling의 특질을 보면, 현재의 exception이 다른 대안들(expected,outcom, 일반적 error code return)보다, 기능적인 측면에서 훨씬 더 이상적 특질을 만족한다. 이전의 다른 제안문도 본적이 있는데 거기서도 그렇게 기술돼 있었다. exception에 대한 그러한 평가가, 최소한 C++표준제안하는 사람들 그룹에서는, 인정되는 공통의견인 거다. 그럼에도 불구하고 현재의 exception은 치명적 약점이 있는데, real-time system에 쓰지를 못한다는 거다. 아예 쓰지를 못한다. 다른 대안들은 기능적 측면에서, 이상적 특질들을, 현재의 exception만큼도 충족시키지 못한다. (그렇기 때문에 위 문서에서와 같은 새로운 제안이 또 나온게 아니겠는가?) 그럼에도 불구하고 그 대안들은 real-time system에 쓰일 수 있다. 최소한, 어디든지 쓰일 수 있지만 가장 후지고 불편한, 그 대안들이 아니면 어쩔 수 없이 써야할, C에서도 쓰이는, 단순 error code return방식보다는 낫기떄문에 그런 대안 모색이 필요한 것이다.
(수정: 위 문서에서 제안하는 방식은, 기존의 대안들과 다르게 모든 ideal error handling 특질을 가진 것을 주장한다. 앞으로 어떻게 될 지는 모르겠음)