On Sunday, 9 February 2014 at 05:57:44 UTC, Jonathan M Davis
wrote:
Exceptions _will_ be slower than other code paths, and you
don't want them to
be the normal code path. Nothing is going to make exceptions as
fast as the
normal code paths either. However, D's exceptions are painfully
Just to be pedantic: this is not true.
If you have frame based exception meta-info recording then a
throw out of recursion (without try-blocks in the recursion) will
be faster than normal returns. You unwind down to the try-block
with loading a register and a single JMP. All you have to do is
to maintain a single linked list of stack frames that can catch.
AFAIK the overhead is neglectible if you avoid doing try-blocks
in light-weight function calls. You store one pointer per
catching stack-frame.
That alone is good enough reason to realize that exception
handling strategy should be a compiler switch, not a language
policy. Because performance depends on what kind of code patterns
you have and the architecture.
On current gen of x86 CPUs the decode stage of instructions into
micro ops and pipelineing ought to be heavy enough that simple
BRA instructions "disappear". Thus the offset strategy ought to
work well too (injecting data into the code stream near the
return point and branch over it if necessary, but usually not).
