Jump to content
  • Advertisement
Sign in to follow this  
Pickl3d

Performance implications of using SEH

This topic is 3746 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I'm curious, if I have a slightly volatile piece of code in an __try {} __except {} block that is called fairly regularly... lets say on a 'per frame' basis. Does this impact the performance in any 'major' way? Currently it seems to run smooth as a button. Just curious.

Share this post


Link to post
Share on other sites
Advertisement
"Once per frame" is "regular", but relatively speaking, it is not "often". Don't worry about it.

Share this post


Link to post
Share on other sites
I wouldn't be concerned about the performance, persay. Two concerns I do have, though:

1) Why are you using SEH instead of C++ exception handling? If you're using C++, SEH is really an inferior solution.

2) Can the exception be avoided altogether? In reality, when things are working correctly and your system is running smoothly, exceptions shouldn't be happening. When issues occur and they need to be handled, then exceptions make more sense. I find exceptions to be an awesome debugging tool, but if exceptions are happening that regularly, their usefulness as a debugging aid starts to decrease. Food for thought.

Share this post


Link to post
Share on other sites
Quote:

1) Why are you using SEH instead of C++ exception handling? If you're using C++, SEH is really an inferior solution.

SEH exceptions are vastly more useful for capturing diagnostic information from non-language exception conditions (e.g., an access violation). C++ exceptions are an abstraction on top of the Windows SEH mechanism and don't cover a lot of the scenarios where you really want to obtain as much information as possible out of the remote program for postmortem analysis.

Quote:

2) Can the exception be avoided altogether? In reality, when things are working correctly and your system is running smoothly, exceptions shouldn't be happening. When issues occur and they need to be handled, then exceptions make more sense. I find exceptions to be an awesome debugging tool, but if exceptions are happening that regularly, their usefulness as a debugging aid starts to decrease. Food for thought.

I read the OP's question (he referred specifically to the "__try {} __except {} block") as being concerned about the performance impact of the setup and teardown neccessary to enter and exit the block, not necessarily the overhead of the exception propagation itself; e.g., he's got a piece of code that gets hit once per frame that enters a __try{} block but may or may not throw.

I would agree that if there is a throw once-per-frame, some reorganization of the codepath is warranted to avoid it -- the throwing (and subsequence unwind) part of any exception implementation is almost always the most expensive.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Quote:

1) Why are you using SEH instead of C++ exception handling? If you're using C++, SEH is really an inferior solution.

SEH exceptions are vastly more useful for capturing diagnostic information from non-language exception conditions (e.g., an access violation). C++ exceptions are an abstraction on top of the Windows SEH mechanism and don't cover a lot of the scenarios where you really want to obtain as much information as possible out of the remote program for postmortem analysis.


Ok, this is true. I'll give you that. Generally, what I've done in the past, is set a structured exception handler that translated the exceptions into custom C++ exceptions, which made the handling much easier and kept the portability aspect. It does keep the code much cleaner. That's all I was getting at. Certainly, using SEH exceptions for your own exceptions doesn't make a lot of sense. I even recall reading that Microsoft was recommending against doing that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!