Ayende @ Rahien

Sony Mathew commented on What is the cost of try/catch

Mon, 19 Sep 2011 17:47:01 GMT

Good to know, Never gave it much thought before. I used to recommended using Checked Exceptions for alternate business flows, yet another reason why that was not a good thing. Now-a-days, I only recommend RuntimeExceptions and that too for exceptional flows (rather than alternate flows). This was for Java by the way - C# doesn't have Checked Exceptions I believe.

Johannes commented on What is the cost of try/catch

Mon, 19 Sep 2011 15:02:05 GMT

maybe I should have put a smiley in there, so that everybody gets the irony :P

Harry Steinhilber commented on What is the cost of try/catch

Mon, 19 Sep 2011 14:23:45 GMT

Here are the results I got: No Try: 10386ms Try inside the loop: 10257ms Try outside the loop: 10330ms So I am not seeing any of the overhead others are claiming to get. (This was done using an x86 release build without the debugger attached, but I got similar results with the debugger and in debug builds.

JDP commented on What is the cost of try/catch

Mon, 19 Sep 2011 00:16:50 GMT

Egh, makes me think of Lucene.Net's god-awful exception-driven query parser.

Yan commented on What is the cost of try/catch

Fri, 16 Sep 2011 13:39:53 GMT

Hi Ayende, great post, really piqued my interest! I did some tests myself and found that a try-catch block itself does seem to add a tiny bit of overhead but the big hit comes from throwing exceptions and the depth of the stacktrace seems to increase the performance cost linearly. http://LNK.by/fkag

Steve Py commented on What is the cost of try/catch

Fri, 16 Sep 2011 13:21:15 GMT

Business logic should not be determing itself based on exeptions, use return values for that. I will use assert-style validations with exceptions to guard against "worse" exceptions such as NullReferenceException. (I've had a play with CodeContracts and frankly I hate them:) These are guards against implementation errors, not validations. For business validations (I.e. valid parameters for a given action) I will create a validator and have it return a meaningful response before deciding whether to continue. Johannes is sort of bang on the money in a hillarious way. Exceptions should be the exception. Generally there are only a few things an exception handler should ever be required to do: (by no means a complete list, but ones I follow) 1) Log an error. 2) Roll back a transaction. 3) Transform an exception into a more meaningful form. Such as cases where the user will be presented with exception details. (I.e. Customer could not be saved. [Inner exception being the SQLException or what-have-you]) This incurs the full cost of exception handling. 4) Ignore an error. (Very, very, very rare case) 1 & 2 sit as high in the code as I can get away with, 3 & 4 tend to dive a bit deeper. (3 used with caution, 4 used only when absolutely necessary.)

Calil commented on What is the cost of try/catch

Wed, 14 Sep 2011 22:25:00 GMT

Ayende, thanks for the post. After the "whether overhead or not" question, the point of our conversation was: is it "nice" to validate business rules throwing exceptions? I still don't see it pretty clear, but I'd rather go with an ActionResult (or something like it) return than throwing exceptions when restrictions are not fulfilled.

Igor Ostrovsky commented on What is the cost of try/catch

Wed, 14 Sep 2011 22:18:58 GMT

Clearing up a few things: * A try-catch does have an overhead to set up, but of course the overhead of a single try-catch will be drowned out by a billion operations. Ayende's test performs some billion operations, but only contains one try-catch. * A try-catch is cheap, but not free. For example: [MethodImpl(MethodImplOptions.NoInlining)] static int F(int a) { // try { return a * 3 + 1; // } catch(Exception e) { return 0; } } When I call F() in a loop on X86 JIT (release, no debugger), the test takes 230ms as is, and 630ms if I uncomment the try-catch. Also, if you don't believe the perf numbers, you can look at the disassembly of the F() method body in the two cases and see the extra instructions that will execute due to the try-catch. * An additional cost of a try-catch is that it can interfere with compiler optimizations. If I remove the MethodImpl attribute from my example, the test takes 37ms without the try-catch, but still 630 ms with the try-catch. The compiler won't inline a method if it contains a try-catch. * So, do you care? Rarely. Try-catch is still cheap - e.g., throwing an exception is far, far more expensive. But, if you have a try-catch in the innermost loop of a program, removing the try-catch may result in non-trivial perf benefits.

NameNick commented on What is the cost of try/catch

Wed, 14 Sep 2011 19:21:01 GMT

@Johannes: Rule of of thumb: Don't make me laugh when I'm eating :)

[ICR] commented on What is the cost of try/catch

Wed, 14 Sep 2011 17:34:58 GMT

@Johannes: Rule of thumb: Don't base your opinions on ambiguous and legacy terminology.

Johannes commented on What is the cost of try/catch

Wed, 14 Sep 2011 14:06:23 GMT

Rule of thumb: Exceptions should be exceptional.

Brian commented on What is the cost of try/catch

Wed, 14 Sep 2011 13:53:07 GMT

And Matt Pietrek (http://msdn.microsoft.com/en-us/magazine/cc301714.aspx).

Brian commented on What is the cost of try/catch

Wed, 14 Sep 2011 13:49:11 GMT

My understanding is that while there's certainly an associated JIT time cost, at actual runtime there is no additional cost because it's not until an exception is thrown that an attempt is made to determine whether a handler was in place for the faulting frame. This topic has been pretty well treated in the past by folks like Chris Brumme (http://blogs.msdn.com/b/cbrumme/archive/2003/10/01/51524.aspx).

Niklas commented on What is the cost of try/catch

Wed, 14 Sep 2011 13:17:12 GMT

By massaging away various compiler optimizations, I'm looking at the following snippets of code in IPSpy: Without try-catch: double num = double.NaN; this.noop(num); num = this.Iteration(total, next); this.noop(num); return num; With try-catch: double num = double.NaN; this.noop(num); try { num = this.Iteration(total, next); } catch (Exception arg_21_0) { Exception value = arg_21_0; Console.WriteLine(value); } this.noop(num); return num; The code without try-catch consistently runs ~7% faster than the other. I might be fudging up the test though, so here's the code: http://pastebin.com/AKeMZNFx

Remco commented on What is the cost of try/catch

Wed, 14 Sep 2011 13:14:36 GMT

edit: ofcourse with the mq.Peek(timeout) call.

Remco commented on What is the cost of try/catch

Wed, 14 Sep 2011 13:13:47 GMT

This reminds me of how you need to peek messages from msmq. try { var mq = new MessageQueue(..) } catch(MessageQueueException e) { if (e.MessageQueueErrorCode == MessageQueueErrorCode.IOTimeout) { // EMPTY QUEUE ?!?!?!?! } } horrible, horrible

MrDustpan commented on What is the cost of try/catch

Wed, 14 Sep 2011 12:41:38 GMT

"Maybe there is something that I don’t know? It is always possible..." - lol

TryCatchInsideFor commented on What is the cost of try/catch

Wed, 14 Sep 2011 12:17:33 GMT

decimal aux = 0; Stopwatch watch = Stopwatch.StartNew(); for (var j = 0; j < 10000000; j++) try { aux += (decimal)Math.Sqrt(Math.PI * j * j / 10 + Math.E * Math.E); } catch (Exception e) { Console.WriteLine(e); } Console.WriteLine(" With try/catch {0}", watch.Elapsed); watch = Stopwatch.StartNew(); aux = 0; for (var j = 0; j < 10000000; j++) aux += (decimal)Math.Sqrt(Math.PI * j * j / 10 + Math.E * Math.E); Console.WriteLine("Without try/catch {0}", watch.Elapsed);

David Fauber commented on What is the cost of try/catch

Wed, 14 Sep 2011 12:09:44 GMT

I avoid excessive try/catch mainly because of an irrational fear of indentation anyway, but its interesting seeing that there's relatively little overhead. Its always been my understanding that generating the stack trace was the biggest perf-hit but I guess I always figured there'd be some inherent minor hit associated with the try/catch blocks as well.

Fabian Wetzel commented on What is the cost of try/catch

Wed, 14 Sep 2011 11:36:48 GMT

@Niklas: have you tried a Release build without attaching the debugger?

Niklas commented on What is the cost of try/catch

Wed, 14 Sep 2011 11:08:29 GMT

Interestingly, I see a pretty consistent 5-10% increase in execution time when wrapping each step of the iteration in a try-catch block (using the average of 100 runs of 1000000 iterations each). There might be something else going on under the hood. Will have a look at the IL.

Boris Yankov commented on What is the cost of try/catch

Wed, 14 Sep 2011 10:27:08 GMT

It has always been the case that THROWING exceptions is expensive. Wrapping code with try/catch blocks isn't. And expensive is quite a relative term. I am pretty sure one can catch tens or hundreds of thousands of exception per second. The rule is to use try/catch for exceptions - uncommon execution paths. It will not be wise to use it instead of if/else blocks.

Koen commented on What is the cost of try/catch

Wed, 14 Sep 2011 10:11:54 GMT

I guess a lot of the performance cost in throwing exceptions is in generating the stack trace?

Ken Egozi commented on What is the cost of try/catch

Wed, 14 Sep 2011 09:58:44 GMT

One might say that your try-catch wrapper is unfair as it only wraps the whole thing once, instead of wrapping each step of the iteration. Of course it does not change anything. On my machine, the first code runs in 8046ms, while wrapping the lambda in try-catch yeilds a 8141ms run time. (running Snow Leopard on my 2.3mhz MBP, using Mono 2.10.5 csharp REPL)