> If you ignore all the syntactic differences and write perfect exception-safe > code vs perfect return-based code, the latter will be the same or faster.
Not necessarily: "In summary, the exceptions approach was 7% smaller and 4% faster as a geomean across our key benchmarks, thanks to a few things: No calling convention impact. No peanut butter associated with wrapping return values and caller branching. All throwing functions were known in the type system, enabling more flexible code motion. All throwing functions were known in the type system, giving us novel EH optimizations, like turning try/finally blocks into straightline code when the try could not throw. There were other aspects of exceptions that helped with performance. I already mentioned that we didn’t grovel the callstack gathering up metadata as most exceptions systems do. We left diagnostics to our diagnostics subsystem. Another common pattern that helped, however, was to cache exceptions as frozen objects, so that each throw didn’t require an allocation: ..." >From the well known <http://joeduffyblog.com/2016/02/07/the-error-model/> How well this translates over to C++'s exception handling implementation is of course not clear but it's simply not as simple as "once correctly written the code with Option/Either performs better". It does not. There are information theoretical reasons for this too: The Option/Either model obfuscates what the hot and what the cold paths look like.
