Performance implications of Exceptions in .NET

• Download source files - 9.23 KB
• Download demo project - 9.25 KB

Introduction

One of the important changes to programming style that .NET brought to developers is the use of exceptions as the primary method of error handling. This is not a revolutionary approach since exceptions have been actively used in various programming languages, but for a generation of programmers trained on traditional Windows and COM APIs, it did require change of their habits. No more HRESULT analysis, no more struggling with E_ACCESSDENIED, no more traversing of records obtained through the IErrorInfo interface. Just throw, try, catch, and finally.

Since the initial release of .NET, there’s been a discussion on whether Microsoft has gone too far with abandoning error codes. In this article, I will not go into arguments on that matter. Larry Osterman from Microsoft in his blog articles "Exceptions as repackaged error codes" and "Error Code Paradigms" covers some aspects of this discussion. An excellent set of guidelines was compiled by Krzysztof Cwalina. Of course, Microsoft also published various recommendations on exceptions' best practices, including "Error Raising and Handling Guidelines". So I will not try to answer the question "to throw or not to throw?". Honestly, if I knew the definitive answer of such a question, I would not have spent time to write programs just to study exceptions behavior. But I don’t. So I felt I had to thoroughly investigate various aspects of using exceptions. And one of the most important aspects is their performance. Exceptions cost. Throwing them without understanding how much they cost may have a negative impact on your application. In this article, I will present performance results measured using different scenarios, including throwing exceptions from methods of different complexity, within a single AppDomain and across domains.

Benchmark application

To collect performance measurements, I have written a small .NET Windows Forms application. Using this application, it is possible to specify the job type, how to throw (or not throw) an exception, and select a time interval while the selected job is executed. When the time expires, the application shows the job execution count. Its main screen is shown in figure 1.

There are five job types that can be executed:

• Empty - As it’s easy to guess, an empty method.
• String processing - A string "The quick brown fox jumps over the lazy dog" is split into words and each word is then uppercased.
• File access - The application reads the contents of every file in the current directory.
• Database - A SQL statement "SELECT * FROM Products" is executed using SQL Server ADO.NET provider and Northwind database.
• Complex - A combination of string (8 times), file (4 times), and database (2 times) operations. This is a simulation of a simple business logic operation, although a very light one, since both file and database operations are read-only.

In addition, the application defines five modes of exceptions:

• No exception - Plain job execution.
• Catch without exception - Method is executed inside a try-catch block, but no exception is thrown.
• Throw - A single exception is thrown and caught after the job is executed.
• Rethrow original - An exception is thrown, caught, and re-thrown.
• Rethrow new - An exception is thrown, caught, and then a new exception is thrown with the original one set as an inner exception.

Since exceptions drag quite a lot of information, in case the method is executed across AppDomains and results in exception, it incurs considerable extra costs related to its serialization. To measure such costs, I have added the possibility to execute selected jobs in a separate AppDomain.

Below I present the results of application execution on my Dell Latitude D800 with Pentium M 1.70 GHz. Every test was executed using a 1 second interval.

The perfect world: no exceptions

To begin with our benchmarking, we need to gather reference data: how fast is the code when no exceptions are thrown? Table 1 shows this information:

It is too early to make conclusions at this stage, but two things can be observed. First, there is no cost in a try-catch block (might sound obvious but I’ve heard arguments that low level code should avoid try-catch blocks for performance reasons). Second, with a difference of 100,000 times between empty and complex operations, it does not make much sense to talk about absolute costs of using exceptions. They must be analyzed in the context of operations.

The real world: exceptions added

Now let’s look at how much the use of an exception costs. The results are shown in table 2:

Here we can see that exceptions do not present a significant performance threat for operations that are more complex than simple calculation algorithms. Only primitive string processing was affected by raised exceptions. As soon as the method involves accessing files or databases (and majority of them do), the cost of exceptions become really marginal.

Another observation is that wrapping an exception in a new one does not really affect the performance compared to re-throwing an original one, so you should not be afraid of doing this just for performance reasons.

The heavy world: sending exceptions across application domains

If you recognize exceptions as the sole method of propagating error information and replace them with numerical traditional error codes, you should be aware of the associated costs of cross-domain exception marshalling. Every exception is a large packet of information that includes even a callstack. When being sent across threads or application domains, this packet is serialized and de-serialized, and of course this comes at a price. Table 3 shows these costs:

As you can see, application domains are performance killers by themselves. An empty method is executed with a speed that is more than 400 times slower than execution within the same domain! Think twice before splitting your components between different domains. However, sometimes this is an only option, and in such cases, exceptions add even more to the performance costs. For simple computational tasks, exception handling will use more than 90% of the processing time. Even for file access operations, cross-domain exception marshalling slows down the execution to almost half the speed. But more complex business logic operations can still afford to throw exceptions even in multiple domain environments.

Conclusion

Exception handling is much more than its performance aspects. Here, I have not touched such topics as whether exceptions should be thrown only in abnormal situations or they should cover all unsuccessful operational states. Perhaps the only conclusion I can draw from the presented results is that for everything but simple computational algorithms, exceptions do not have a big impact on performance, at least not big enough to make a design decision regarding exceptions based mostly on performance reasons. You should carefully apply the guidelines presented in the referenced articles and in case performance is of high concern, implement additional methods that will help avoid unnecessary raising of exceptions (Tester-Doer and Try-Parse patterns in Krzysztof Cwalina’s article). But in general, exceptions will fit in most architectures without a noticeable performance impact.

References

1. Exception Throwing Guidelines by Krzysztof Cwalina
2. Exceptions as repackaged error codes by Larry Osterman
3. Error Code Paradigms by Larry Osterman
4. Error Raising and Handling Guidelines by Microsoft