Overhead of Win32 and C++ exception handling
Urs Meier
I've read some articles about exception handling, because I'd like to
use it to handle fatal errors in my DirectX game framework, no matter
where they occur, and to give the framework user a way to free
allocated resources, no matter when the application is terminating.
But I've read that exception handling can cause a big performance
overhead. Since my framework is a game framework where performance
plays a major role, I'm wondering which type of exception handling
mechanism has the smaller performance overhead: Win32 (structured)
exception handling or C++ exception handling? (I'm using the Visual
C++ compiler, BTW.)
I'm also wondering when the penalty comes into play: When leaving the
scope of any function which was called within a __try/__except or
try/catch block (no matter how the block was left), or only at the
point where an exception is raised/thrown?
The only thing I know for sure is that Win32 exception handling
doesn't unwind the stack when an exception occurs which means no
destructors of objects on the stack are called, whereas C++ exception
handling does unwinding. So Win32 exception handling is the way to go
when speed has priority?
BTW, does anybody know if the OS of the X-Box supports Win32 exception
handling?
Thanks in advance.
Urs
Marc Hernandez
: Hi everybody!
: I've read some articles about exception handling, because I'd like to
: use it to handle fatal errors in my DirectX game framework, no matter
: where they occur, and to give the framework user a way to free
: allocated resources, no matter when the application is terminating.
A very good thing.
: But I've read that exception handling can cause a big performance
: overhead. Since my framework is a game framework where performance
: plays a major role, I'm wondering which type of exception handling
: mechanism has the smaller performance overhead: Win32 (structured)
: exception handling or C++ exception handling? (I'm using the Visual
: C++ compiler, BTW.)
Try them out, look at the assembly output etc. I have played a
bit with them and it looks like there is one extra 'mov' inserted where
the try is.
Oddly this can effect the optimizer and cause try/catch code to be
faster (because certain optimizations become availble presumably) than
non.
However the code that is written becomes much cleaner looking, as
well as safer (if one follows good C++ practices).
: I'm also wondering when the penalty comes into play: When leaving the
: scope of any function which was called within a __try/__except or
: try/catch block (no matter how the block was left), or only at the
: point where an exception is raised/thrown?
: The only thing I know for sure is that Win32 exception handling
: doesn't unwind the stack when an exception occurs which means no
: destructors of objects on the stack are called, whereas C++ exception
: handling does unwinding. So Win32 exception handling is the way to go
: when speed has priority?
Well, you want to properly deconstruct your C++
objects. Something wrong happened in your code (thus the exception) and
you want to properly recover from it.
I use them whenever it makes the code cleaner.
: BTW, does anybody know if the OS of the X-Box supports Win32 exception
: handling?
I bet it will. There are *other* consoles that support such
things as exceptions, stl, C++.
Marc
Ondrej Necasek
Urs Meier wrote:
>
> Hi everybody!
>
> I've read some articles about exception handling, because I'd like to
> use it to handle fatal errors in my DirectX game framework, no matter
> where they occur, and to give the framework user a way to free
> allocated resources, no matter when the application is terminating.
>
Internally, C++ exception handling uses the SEH features. This might
not
necessarily be the case for every C++ compiler but MSVC++, Watcom C/C++
and IBM VisualAge C++ all do that.
Entering a try...catch block means registering an exception handler.
Doing a throw in C++ simply calls the RaiseException API.
C++ exceptions are more expensive than SEH because the compiler needs
to record some extra information.
About performance... you probably wouldn't want to get in and out of
try...catch blocks too often. There is some performance hit there.
If you want to register only few exception handlers for longer time,
that's OK. But using exception handling everywhere instead of plain
if ((rc = APICall()) == ERROR) {...} isn't optimal. Exception handling
is OK for exceptional situations but not for everything.
Ondrej Necasek