How slow are exceptions?
Author
I always hear people saying they can be slow for game programming, therefore being reasonable the choice of return codes. But how slow are they?
I mean on code that is not close to being performance critical. That would be initializing some API subsystems, file loading, thread creation (not execution), and stuff like that.
Premature optimization is the root of all evil, particularly when your premature optimization tosses by the wayside one of the tools that will make you a more productive and effective programmer.
Use exceptions until you've profiled your application and determined that exceptions cost too much.
Chances are you'll never encounter the point where the overhead matters. Is there some overhead? Yeah, but it varies from language to language and from compiler to compiler (there's more than one way to implement C++'s exception model, for instance).
Also, if you're using a framework like XNA, you can't avoid exceptions anyway.
Personally, I've never bought into the opinion that the cost of using exceptions outweighs the benefits they provide.
Use exceptions until you've profiled your application and determined that exceptions cost too much.
Chances are you'll never encounter the point where the overhead matters. Is there some overhead? Yeah, but it varies from language to language and from compiler to compiler (there's more than one way to implement C++'s exception model, for instance).
Also, if you're using a framework like XNA, you can't avoid exceptions anyway.
Personally, I've never bought into the opinion that the cost of using exceptions outweighs the benefits they provide.
Since exceptions should be relatively rare, and only occur when something EXCEPTIONal happens, something that wasn't expected. Performance should be the least of your worries in these cases.
Exceptions are problematic in C++ due to somewhat inconsistent handling. There's nothing really wrong with them, there are just semi-valid reasons why many developers dislike their design as it is.
Performance penalty in C++ comes from increased code size, and prolog/epilog code that's inserted at certain places.
For all practical purposes, the hit due to this will be < several %, compared to code with *no* error handling whatsoever.
The only cost that does occur, is propagation of exceptions (creating exception class, populating the data, copying it as needed, destroying the object). But since those are exceptional situations, something is breaking down, so performance isn't your concern.
For managed languages (the likes of C#), the question is irrelevant. Exceptions are normal part of that language, and normalized impact doesn't matter - a better question would be, if you're generating thousands of exceptions per second, shouldn't you rethink your code flow?
All of the above applies only when and if exceptions are used for exceptional situations. It doesn't apply if they are abused for return codes, or even worse cases.
Performance penalty in C++ comes from increased code size, and prolog/epilog code that's inserted at certain places.
For all practical purposes, the hit due to this will be < several %, compared to code with *no* error handling whatsoever.
The only cost that does occur, is propagation of exceptions (creating exception class, populating the data, copying it as needed, destroying the object). But since those are exceptional situations, something is breaking down, so performance isn't your concern.
For managed languages (the likes of C#), the question is irrelevant. Exceptions are normal part of that language, and normalized impact doesn't matter - a better question would be, if you're generating thousands of exceptions per second, shouldn't you rethink your code flow?
All of the above applies only when and if exceptions are used for exceptional situations. It doesn't apply if they are abused for return codes, or even worse cases.
Author
Quote:Original post by SiCrane
Which programming language are you asking about?
Any programming language. C++, Java, C#... just wanted to know the general impact on the most used languages.
Got the answers I needed. Thanks.
It's worth noting that exception handling in Java is quite fast (negligable overhead for entering a try/catch, and actually throwing and catching an exception is fast too), but the construction of the Exception object itself can be quite slow (relatively speaking). More precisely, constructing the stack trace to go inside the Exception object is what takes the time. Therefore if you must use an exception is a performance-critical section of the code, you can pre-create the exception object (say, at level load time) so that you can throw the exception without the speed hit.
Quote:Original post by OrangyTang
It's worth noting that exception handling in Java is quite fast (negligable overhead for entering a try/catch, and actually throwing and catching an exception is fast too), but the construction of the Exception object itself can be quite slow (relatively speaking). More precisely, constructing the stack trace to go inside the Exception object is what takes the time.
This is true for all languages.
Which is why it's important to use exceptions for exceptional things. Java frameworks tend to abuse them to no end. But that, as with any language, is not the problem of language itself.
Same considerations apply to everything else, C++ as well. When people say exceptions are slow in C++, they mean that after 6 months of optimization of every single aspect of the engine, they could squeeze additional 3% out by disabling them altogether.
Quote:Therefore if you must use an exception is a performance-critical section of the code, you can pre-create the exception object (say, at level load time) so that you can throw the exception without the speed hit.
How many exceptions do you throw? Tens of thousands? Per level load? Shouldn't there be either zero or one (in which case you fail to load the level).
Quote:Original post by AntheusQuote:Original post by OrangyTang
It's worth noting that exception handling in Java is quite fast (negligable overhead for entering a try/catch, and actually throwing and catching an exception is fast too), but the construction of the Exception object itself can be quite slow (relatively speaking). More precisely, constructing the stack trace to go inside the Exception object is what takes the time.
This is true for all languages.
C++ exceptions don't even build a stack trace, how can that be the slow part? I think you're confusing this with the actual stack unwinding code, which in Java is completely different from building the stack trace within the Exception object itself.
Quote:Quote:Therefore if you must use an exception is a performance-critical section of the code, you can pre-create the exception object (say, at level load time) so that you can throw the exception without the speed hit.
How many exceptions do you throw? Tens of thousands? Per level load? Shouldn't there be either zero or one (in which case you fail to load the level).
You're missing the point. Yes, you probably shouldn't be throwing lots of exceptions during the normal flow of your code, but if for some reason that's unavoidable, then you can avoid the slow stack trace generation by using a pre-canned Exception object.
Quote:Original post by AntheusQuote:Original post by OrangyTang
It's worth noting that exception handling in Java is quite fast (negligable overhead for entering a try/catch, and actually throwing and catching an exception is fast too), but the construction of the Exception object itself can be quite slow (relatively speaking). More precisely, constructing the stack trace to go inside the Exception object is what takes the time.
This is true for all languages.
Over generalize much? This is not the case for C++ exceptions under most exception implementations. Construction of the exception object is usually much faster than the time it takes for throwing and catching the exception; exception objects in C++ do not contain the stack trace. Taking Windows based C++ implementations as an example, which tend to use Structured Exception Handling as an implementation, actually throwing an exception has non-negligible overhead since that requires construction of the exception record (which is not part of the C++ exception object), checking for the presence of a debugger, search for a frame-based exception handler and then triggering the frame-based exception handler, which in C++ subsequently quite often re-raises the exception due to the joys of destruction of objects on the stack, which means it goes through the whole rigmarole all over again.
For that matter, that's not even the case for .NET languages with Microsoft's .NET implementation since .NET exceptions are implemented with the same underlying mechanism that C++ exceptions on the MS platform are implemented: SEH. On the plus side, with the .NET exceptions there tend to be fewer frame-based exception handlers that will just re-raise the exception. On the downside, .NET exceptions do contain the stack trace, so the cost of construction for the .NET exception object bulks up quite a bit more than the C++ exception object.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
