I have received an email in response to this article which claimed that throwing 5000 exceptions to a stack depth of 1000 was taking nearly ten minutes. Now, the correspondent acknowledged that a stack depth of 1000 was very rare, but even so this figure seemed very high to me. I ran the short but complete program that he'd kindly sent me and which he'd used to get his figures. (He'd also provided the results he'd seen. This is very much the kind of thing I look for when someone disagrees with me - the cause of the disagreement and the means of reproducing it. It's a far more productive basis for discussion than just words.) So of course, I ran his program.

The same program that took over nine minutes on his box took about about 47 milliseconds to run on mine. Now, while I'm very happy with my recent laptop purchase, I find it hard to believe it's over 10,000 times faster than my correspondent's box. Looking for explanations, I ran the same program having recompiled it under the .NET 2.0 beta 2, and it took 250 milliseconds. That's significantly slower, but not nearly slow enough to explain the discrepancy.

I then ran it under the debugger of Visual Studio 2003. It took nearly 6 minutes. Now, that's much closer - close enough to easily be explicable by hardware differences. So, it's reasonable to assume that my correspondent was running his code under a debugger. Why is that important? Because the performance when running under a debugger is unimportant.

You should usually only run code under a debugger when you're debugging - hence the name! When you're debugging, performance shouldn't usually be important - the only case I can immediately think of where it is important is where you have an error which crops up one in a million times, and you need to run some code a million times before you can diagnose the problem. Well, if you're in that situation and each of those million runs requires an exception to be thrown from a very deep stack, you may have a problem unless you're willing to leave a machine running the test overnight. Personally, I can't remember the last time I was in that situation.

I am utterly convinced that the cost of exceptions in the debugger is the cause of a lot of the myth about the general cost of exceptions. People assume that a similar cost is present when running outside the debugger when it just isn't. (It doesn't matter much whether you run a debug version of the code or not - it's whether a debugger is attached or not that matters.) This is made worse by the way that the first exception thrown under a debugger can take a few seconds (although I still haven't worked out why this happens - it doesn't seem to involve hard disk or CPU activity). I've seen developers claim that exceptions each take a second or two to be thrown - something that would render them much, much less useful.

Note that it's not only exceptions which fall foul of this. The debugger disables lots of optimisations the JIT can normally make, including inlining (in at least some places). If you take too much notice of performance in the debugger without testing outside the debugger, you could easily end up making optimisations which only make a significant difference in the debugger, but which hurt your design and readability.