Comments on: Try/Catch Blocks Can Hurt Performance

By: Jarmo

Jarmo — Fri, 24 Dec 2010 13:53:38 +0000

I was curious about try-catch penalty, and I found this page, but it did not clearly told me is there a penalty or not. I wrote code to prove.

System.DateTime start = System.DateTime.Now;
// 100 million times
for( int index = 0; index < 100000000; ++index)
{
try
{
int x = index;
}
catch( System.Exception )
{
}
finally { }
}
System.DateTime end = System.DateTime.Now;
double elapsed = (end – start).TotalMilliseconds;

250ms without try-catch-finally
484ms with try-catch
875ms with try-catch-finally
750ms with try-finally

I can now relax and write try-catch. Of course I use it only for exceptions, which occur seldomly.

By: Ian

Ian — Fri, 01 Oct 2010 17:00:10 +0000

If you are for example iterating a list of 100,000 items, and out of that list, perhaps you may encounter 1 or exception situations, would it be more performant to do an if check 100,000 times, or to remove the if check, and allow your exception block to handle the ‘exceptional situation’, say perhaps a null reference or something?

By: [Перевод] Лучшие практические решения обработки исключений в веб-приложениях ASP.NET - Александр Гончарук - технический блог - Microsoft User Group Винн�

Sat, 19 Jun 2010 17:37:45 +0000

[…] Try/Catch Blocks Can Hurt Performance Significantly – Chinh Do […]

By: Using JavaScript’s Try-Catch Statement | 610 Design

Using JavaScript’s Try-Catch Statement | 610 Design — Thu, 08 Apr 2010 10:48:10 +0000

[…] short answer seems to be yes, although this article on MSDN says that performance is affected only when the catch portion […]

By: Using JavaScript’s Try-Catch Statement | Impressive Webs Toronto

Using JavaScript’s Try-Catch Statement | Impressive Webs Toronto — Tue, 06 Apr 2010 14:48:52 +0000

[…] short answer seems to be yes, although this article on MSDN says that performance is affected only when the catch portion […]

By: Chinh Do

Chinh Do — Sat, 06 Feb 2010 16:37:12 +0000

In reply to Derk. Hi Derk: Thanks for your comment. I agree with you. My example is an example of bad exception handling, so definitely don't do it like that. Chinh

By: Derk

Derk — Sat, 06 Feb 2010 11:20:04 +0000

The thing that I see missing in this discussion is that exceptions should only be used for _exceptional_ behaviour. In your example, Chinh, you’ve used exceptions for expected behaviour. In general, exceptions are a great thing, and they don’t affect performance. Just don’t write code that depends on them being called.

By: Dmitriy

Dmitriy — Tue, 15 Dec 2009 19:00:09 +0000

This is would be the best way to do this try catch block
w.Start();
int notFound = 0;
try
{
for (int i = 1; i <= 1000000; i++)
{
int value = numbers[i];
}
}
catch
{
notFound++;
}
this.label1.Text = “Elapsed: ” + w.ElapsedMilliseconds + “.”;

By: Chinh Do

Chinh Do — Wed, 26 Aug 2009 16:47:21 +0000

Hi thedudeewr: Thanks for you comment. The point of the ProgrammerHeaven article is absolutely correct… there’s no significant performance issue with one single empty try/catch block.

My main point was only to add “but be careful”… even if the empty try/catch block doesn’t impose any performance issue, we usually have some type of code inside the catch block… and that code may be an issue when it gets triggered, especially in a loop. That’s all.

Anyway, I guess I didn’t say what I wanted to say clearly. I can see how my post could be misunderstood as trying to refute the ProgrammerHeaven’s article.

By: thedudeewr

thedudeewr — Wed, 26 Aug 2009 16:08:10 +0000

sorry but while you might be true , youre not comparing apples to apples, you should take a class in algorithm analisys. the question is wheter ONE try catch hurts performance (and some memory) , and the article you linked answers this, only adds a litle more to memory and performance, if you insert it in a loop then u multiply this by n so then the algorithm goes to O(n), to prove your point you will have get as result a O(n^2) or higher to make your point.
what you are saying is like comparing creating one integer as opposed to creating integers inside a loop. but anyway good try.