Click here to Skip to main content
15,867,686 members
Articles / Programming Languages / C#

Performance implications of Exceptions in .NET

Rate me:
Please Sign up or sign in to vote.
4.45/5 (66 votes)
9 Aug 2005CPOL7 min read 218.8K   976   105   37
Presentation and analysis of performance costs when throwing exceptions in .NET.

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.

Image 1

Figure 1. Exception performance benchmark application.

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:

Mode/operationEmptyStringFileDatabaseComplex
No exception17,748,206267,3002,461877239
Catch without exception15,415,757261,4562,476871236
Table 1. No exceptions thrown (executions per second).

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:

Mode/operationEmptyStringFileDatabaseComplex
Throw103,45668,9522,236864236
Rethrow original53,48141,8892,324852230
Rethrow new55,71243,1402,269847232
Table 2. Exceptions thrown (executions per second).

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:

Mode/operationEmptyStringFileDatabaseComplex
No exception44,43736,1011,458749175
Throw3,0732,942930574160
Rethrow original2,9502,881929588158
Rethrow new2,8822,875938577158
Table 3. Exceptions thrown across domains (executions per second).

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

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Architect Miles AS
Norway Norway
Vagif Abilov is a Russian/Norwegian software developer and architect working for Miles. He has more than twenty years of programming experience that includes various programming languages, currently using mostly C# and F#.

Vagif writes articles and speaks at user group sessions and conferences. He is a contributor and maintainer of several open source projects, including Simple.Data OData adapter, Simple.OData.Client and MongOData.

Comments and Discussions

 
Questionuseful info Pin
BillW3321-Dec-11 6:58
professionalBillW3321-Dec-11 6:58 
GeneralMy vote of 1 Pin
Joe Woodbury12-Jan-09 7:24
professionalJoe Woodbury12-Jan-09 7:24 
GeneralRe: My vote of 1 Pin
PIEBALDconsult9-May-09 9:03
mvePIEBALDconsult9-May-09 9:03 
GeneralRe: My vote of 1 PinPopular
Vagif Abilov9-May-09 11:36
professionalVagif Abilov9-May-09 11:36 
GeneralI dont care what anybody says.... Pin
Nick Z.16-Aug-05 8:16
Nick Z.16-Aug-05 8:16 
GeneralRe: I dont care what anybody says.... Pin
Vagif Abilov18-Aug-05 23:59
professionalVagif Abilov18-Aug-05 23:59 
GeneralRe: I dont care what anybody says.... PinPopular
Zoltan Balazs7-Mar-07 6:50
Zoltan Balazs7-Mar-07 6:50 
QuestionTo throw or not to throw...? Pin
ptmcomp15-Aug-05 8:42
ptmcomp15-Aug-05 8:42 
AnswerRe: To throw or not to throw...? Pin
Vagif Abilov18-Aug-05 23:59
professionalVagif Abilov18-Aug-05 23:59 
QuestionPoint? Pin
Peter Ritchie15-Aug-05 5:55
Peter Ritchie15-Aug-05 5:55 
AnswerRe: Point? Pin
elmar_bartowitsch15-Aug-05 23:21
elmar_bartowitsch15-Aug-05 23:21 
GeneralRe: Point? Pin
Peter Ritchie16-Aug-05 3:21
Peter Ritchie16-Aug-05 3:21 
GeneralRe: Point? Pin
Portatofe2-Oct-08 6:00
Portatofe2-Oct-08 6:00 
AnswerRe: Point? Pin
Vagif Abilov18-Aug-05 23:57
professionalVagif Abilov18-Aug-05 23:57 
QuestionAre exception a good thing? Pin
ediazc11-Aug-05 17:55
ediazc11-Aug-05 17:55 
QuestionAre you all insane? Pin
KingJinx10-Aug-05 16:00
KingJinx10-Aug-05 16:00 
AnswerRe: Are you all insane? Pin
Vagif Abilov10-Aug-05 20:31
professionalVagif Abilov10-Aug-05 20:31 
GeneralGreat article -- and TryParse in .NET 2.0 Pin
wumpus110-Aug-05 12:50
wumpus110-Aug-05 12:50 
GeneralRe: Great article -- and TryParse in .NET 2.0 Pin
Vagif Abilov10-Aug-05 20:21
professionalVagif Abilov10-Aug-05 20:21 
GeneralGood and informative work Pin
Super Lloyd10-Aug-05 2:32
Super Lloyd10-Aug-05 2:32 
GeneralRe: Good and informative work Pin
Vagif Abilov10-Aug-05 3:35
professionalVagif Abilov10-Aug-05 3:35 
GeneralExcellent Reference Pin
Matt Gerrans9-Aug-05 19:47
Matt Gerrans9-Aug-05 19:47 
GeneralRe: Excellent Reference Pin
Vagif Abilov9-Aug-05 20:16
professionalVagif Abilov9-Aug-05 20:16 
GeneralException...ally Pin
ian mariano9-Aug-05 15:31
ian mariano9-Aug-05 15:31 
GeneralRe: Exception...ally Pin
Vagif Abilov9-Aug-05 19:11
professionalVagif Abilov9-Aug-05 19:11 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.