try catch performance

Question

This article on MSDN states that you can use as many try catch blocks as you want and not incur any performance cost as long no actual exception is thrown.
Since I always believed that a try-catch always takes a small performance hit even when not throwing the exception, I made a little test.

 private void TryCatchPerformance()         {             int iterations = 100000000;              Stopwatch stopwatch = Stopwatch.StartNew();             int c = 0;             for (int i = 0; i < iterations; i++)             {                 try                 {                    // c += i * (2 * (int)Math.Floor((double)i));                     c += i * 2;                 }                 catch (Exception ex)                 {                     throw;                 }             }             stopwatch.Stop();             WriteLog(String.Format("With try catch: {0}", stopwatch.ElapsedMilliseconds));              Stopwatch stopwatch2 = Stopwatch.StartNew();             int c2 = 0;             for (int i = 0; i < iterations; i++)             {               //  c2 += i * (2 * (int)Math.Floor((double)i));                 c2 += i * 2;             }             stopwatch2.Stop();             WriteLog(String.Format("Without try catch: {0}", stopwatch2.ElapsedMilliseconds));         } 

The output I get:

With try catch: 68 Without try catch: 34 

So it seems that using no try-catch block seems to be faster after all?

What I find even more strange is that when I replace the computation in the body of the for-loops by something more complex like: c += i * (2 * (int)Math.Floor((double)i));
The difference is far less dramatic.

With try catch: 640 Without try catch: 655 

Am I doing something wrong here or is there a logical explanation for this?

Answer 1

The JIT doesn't perform optimization on 'protected' / 'try' blocks and I guess depending on the code you write in try/catch blocks, this will affect your performance.

Answer 2

The try/catch/finally/fault block itself has essentially no overhead itself in an optimized release assembly. While there is often additional IL added for catch and finally blocks, when no exception is thrown, there is little difference in behavior. Rather than a simple ret, there is usually a leave to a later ret.

The true cost of try/catch/finally blocks occurs when handling an exception. In such cases, an exception must be created, stack crawl marks must be placed, and, if the exception is handled and its StackTrace property accessed, a stack walk is incurred. The heaviest operation is the stack trace, which follows the previously set stack crawl marks to build up a StackTrace object that may be used to display the location the error happened and the calls it bubbled through.

If there is no behavior in a try/catch block, then the extra cost of 'leave to ret' vs. just 'ret' will dominate, and there will obviously be a measurable difference. However, in any other situation where there is some kind of behavior in the try clause, the cost of the block itself will be entirely negated.