Overhead of exception handling in D

Question

In the D2 programming language, what are the performance implications of using exception handling? In particular:

• What if I write no exception handling code?
• What if I do, but no exceptions are ever thrown?
• What if I do, and exception are thrown?
• Does exception handling cause any optimization opportunities to be missed?
• Can exception handling be disabled like it can in many (most?) C++ implementations?

I know that almost all commercial game development studios disable exception handling in their C++ due to the performance implications and increased development time associated with correctly handling exceptions. I know D makes that latter less painful, but what about performance?

Of course, this is all probably implementation defined, so for this question, please focus on the DMD compiler.

Answer 1

As far as I am aware, DMD uses whatever the native mechanism on the platform is. On Windows, this would be Structured Exception Handling which is what is also used by MSVC++ to implement exceptions.

On linux, I believe it uses the same exception tables mechanism that GCC uses. On other platforms, I don't know.

In terms of performance, it's probably the same (or at least very close) to C++.

Answer 2

I cannot speak about D or any of its compilers, but I can tell you some about C++, Windows, and the Visual Studio compiler. This might help you understand roughly how D does things.

First, exception handling on 32- and 64-bit machines is different. The x86 ABI (prolog/epilog, unwinding, calling convention) is more lax, so the compiler and the program itself must do more work. The x86-64 ABI is stricter and the OS plays a bigger role, making it easier for the program itself to work with exceptions. If you're running D on Windows, then it likely uses SEH (structured exception handling) like C++ does.

Again, all of my answers below relate to Windows, C++, and Visual Studio.

What if I write no exception handling code?

x86/x86-64: There is no cost for that method.

What if I do, but no exceptions are ever thrown?

x86: There is a cost even when exceptions aren't thrown. Exception handling information is pushed into the TIB (thread information block) such as the initial scope and the function-specific exception handler. In order to know what objects to destruct and what handlers to search, a scope variable is maintained. This scope variable is updated as you enter try blocks and construct stack objects that have destructors.

x86-64: Because of the stricter rules, there is no extra code (or very very minimal). This is a big advantage over x86.

What if I do, and exception are thrown?

On either x86 or x86-64, there will definitely be a hit. Exceptions should be exceptional though. Do not use them for regular control flow. Only use them to signal truly exceptional, unexpected events. Essentially, you should never have to worry about the cost of exceptions. Even if they took 2 seconds, you shouldn't care, because they should only happen when everything is going south anyway.

With that said, throwing exceptions on x86-64 is more expensive than throwing them on x86. The x86-64 architecture is optimized around the case of no exceptions being thrown, which, ideally, is nearly all the time.

---

Big picture:

• I can't see propagating error codes being materially faster than exception handling, especially on x64 platforms.
• I doubt you will ever find exception handling being a problem unless you're abusing exceptions.
• If you're unsure, you should measure the performance of your code.