Chinh Do

Try/Catch Blocks Can Hurt Performance Significantly

26th February 2008

Try/Catch Blocks Can Hurt Performance Significantly

posted in Dotnet/.NET - C#, Programming |

Over at Programmers Heaven.com, there’s an interesting article on the potential performance impact of try/catch blocks. The article concluded that the average cost of a try/catch block is essentially nothing (sorry there’s no author information on the post so I couldn’t tell who wrote it), and that .NET/C# programmers should not think twice about using try/catch blocks.

The author is right that a try/catch block has essentially zero cost. However, like most coding performance issues, exceptions and try/catch blocks do not have performance implications until they occur in some type of loop. Something like this will do the job:

Dictionary<int, int> numbers = new Dictionary<int, int>();
Stopwatch w = new Stopwatch();
w.Start();
int notFound = 0;
for (int i = 1; i <= 1000000; i++)
{
    try
    {
        int value = numbers[i];
    }
    catch (KeyNotFoundException)
    {
        notFound++;
    }
}

w.Stop();
Console.WriteLine(notFound);
Console.WriteLine("Elapsed: " + w.ElapsedMilliseconds + ".");

In the block of code above, I am trying to find the number of integers from 1 to 1,000,000 that are not in the numbers dictionary. One way to do it is to try to access the dictionary item by key. Since the Dictionary class will throw a KeyNotFoundException if the key is not found, that’s how I am going to know whether each value is in the dictionary or not.

Well, let’s just see how long that code takes to run. On my virtual PC it took … hold on a sec, it’s till running… still waiting… not quite there yet… finally: 101031 (101 seconds).

If you have any doubt, this is the type of try/catch block or exception handling they advice against. :-)

The above logic, when implemented correctly without using a try/catch block, took only 10 milliseconds. Yes, that’s not a typo: 10 milliseconds. Oh, only about 10,000 times faster.

Here’s the correct code:

Dictionary<int, int> numbers = new Dictionary<int, int>();

Stopwatch w = new Stopwatch();
w.Start();

int notFound = 0;
for (int i = 1; i <= 1000000; i++)
{
    if (! numbers.ContainsKey(i))
    {
        notFound++;
    }
}

w.Stop();
Console.WriteLine(notFound);
Console.WriteLine("Elapsed: " + w.ElapsedMilliseconds + ".");

So, do consider performance impact when using exceptions and try/catch blocks. Avoid using exception handling to implement normal program flow. Here are some links on exception handling best practices in .NET:

kick it on DotNetKicks.com

This entry was posted on Tuesday, February 26th, 2008 at 1:38 am and is filed under Dotnet/.NET - C#, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

There are currently 14 responses to “Try/Catch Blocks Can Hurt Performance Significantly”

  1. 1 On February 26th, 2008, Tim B said:

    I think you somewhat misunderstood the article you linked to. The author is saying that there is a penalty if the program flow enters the catch block (even without a loop), but that **the existence of a try/catch block itself does not inherently affect performance**. In the article summary: “The overall cost of a try…catch block that never handles an exception is a few bytes of memory”. That said, you are correct that regularly handling an exception within a loop will have horrific effects on performance. The safest code would probably include a try/catch around the entire loop in your final example.

    posted on February 26th, 2008 at 3:21 pm

  2. 2 On February 26th, 2008, X4lldux said:

    Yeah, you’re right, but writing code in the 1 style is just crap and should not be doing! So essentially exceptions are zero cost but when they occur they are huge performance drop down. But when shit happens performance isn’t really the case.

    posted on February 26th, 2008 at 3:40 pm

  3. 3 On February 26th, 2008, Darrell said:

    Shouldn’t the correct example be

    if (!numbers.ContainsKey(i))
    {
    notFound++;
    }

    While I agree with the core message of being aware of the performance impact of try..catch I think the code example is not necessarily the best. It seems like just a poor programming example.

    posted on February 26th, 2008 at 3:58 pm

  4. 4 On February 26th, 2008, Chinh Do said:

    Thanks for everyone’s comments.

    My example is a little bit on the extreme side but it’s to prove a point: that bad/incorrect use of structured exception handling CAN lead to performance problems.

    The Programmers Heaven article does say in its conclusion that the performance hit of a try/catch block that never handles an exception is virtually nothing. I totally agree with that.

    However, by virtue of having a try/catch block, there is the possibility that it WILL catch and handle an exception :-). I also think that many programmers will read the PH article and come out with the wrong conclusion that they should never worry about performance issues with exception handling.

    Darrell: Thanks for pointing out the typo in my code. Corrected.

    posted on February 26th, 2008 at 7:50 pm

  5. 5 On February 26th, 2008, Wesner Moise said:

    “Structured exception handling” refers to a specific Win32 OS feature, not the .NET feature…

    There is no cost to using try/catch within loops or anywhere else, other than the loss of inlining opportunities.

    Costs only arise when exceptions are raised. As a general rule, you should not be relying on exceptions for normal programming tasks. Exceptions are generally for exceptional events, and take up orders of magnitude even outside loops because of stack walking and a variety of other activities.

    You had multiple options that avoided the use of exceptions:
    1) Use TryGetValue
    2) Use ContainsKey

    posted on February 26th, 2008 at 8:28 pm

  6. 6 On February 26th, 2008, Chinh Do said:

    Wesner: I am sure “structured exception handling” can be used to refer generically to the try/catch exception handling syntax. Here are some examples from Microsoft: Examples: http://support.microsoft.com/kb/816157, http://support.microsoft.com/kb/315965, Intro to Structured Exception Handling.

    I agree with your other points. Bad/inappropriate use of exception handling can lead to performance issues and should be avoided.

    posted on February 26th, 2008 at 8:46 pm

  7. 7 On February 27th, 2008, Reflective Perspective - Chris Alcock » The Morning Brew #41 said:

    […] Try/Catch Blocks Can Hurt Performance Significantly - The Try/Catch performance debate continues… […]

    posted on February 27th, 2008 at 4:21 am

  8. 8 On February 27th, 2008, James Curran said:

    Ok, I’m ignoring the entire point of the article, but ….isn’t the actual “correct” method:

    int notused = 1000000 - numbers.Count;

    Yes, using exceptions for non-exception occurences is bad. Dumb algorithms are just as bad.

    posted on February 27th, 2008 at 1:26 pm

  9. 9 On February 27th, 2008, Chinh Do said:

    James:

    I guess I could have done a better job explaining the code example. Perhaps a comment here and there would have helped.

    My point was not to demonstrate good/realistic algorithm, but to highlight the fact that bad exception handling practice can potentially be harmful to your performance. If it helped, please pretend that the Dictionary is passed to you from somewhere else. I don’t think anybody would write real code like that.

    Nice alternate algorithm though.

    posted on February 27th, 2008 at 5:18 pm

  10. 10 On March 14th, 2008, ovation said:

    Chinh,

    This is a great example, bah on the nay-sayers. We are smart enough to know what you mean. Thanks for showing how some simple design decisions and checking can enhance performance!

    Keep up the good work, love the blog!

    -brian

    posted on March 14th, 2008 at 8:02 am

  11. 11 On April 16th, 2008, Milivoj Savin said:

    James,

    Your answer only works if you know that all your keys are all in the range 1 to 1000000. What if the container has a key of 1000001 in it? Can’t Count that.

    posted on April 16th, 2008 at 5:33 am

  12. 12 On June 20th, 2008, Luís Soares said:

    Wouldn’t be faster to get the list of keys and only iterate on them?

    posted on June 20th, 2008 at 8:55 am

  13. 13 On September 15th, 2008, tommy said:

    wouldn’t it just be faster to not do any of that code? Seems like if you skipped it all you could just avoid all the code and exceptions in the first place :)

    posted on September 15th, 2008 at 12:21 am

  14. 14 On September 17th, 2008, Chinh Do said:

    Tommy: Yes you are 100% right. My code example is not a very good one.

    posted on September 17th, 2008 at 8:23 pm

Leave a Comment