Performance Implications of try/catch/finally

re: Performance Implications of try/catch/finally

PeterRitchie — Thu, 24 Sep 2009 13:52:44 GMT

@bmm60: The point of the article *is* to show that using try/catch does impact performance. What you take out of the post, is up to you. How, otherwise, would you show that try/catch does affect performance if you don't show the analysis of two different snippets of code--that differ only by the addition of a try/catch?

It's true that the second can't be optimized the same as the first; but that's because of the added try/catch (or try/finally in C#).

Changing the code to what Norman suggests (i.e. comparing linear code to looping code with a try/catch) most certainly would be comparing apples to oranges. It would then be the very post you're saying it already is. It wouldn't tell you anything--you couldn't see the difference in optimizations of the same code with and without a container try/catch.

The code *could* use a catch block and push the WriteLine outside the try/catch; but, it would show the same thing without adding any clarity, IMO.

re: Performance Implications of try/catch/finally

bmm6o — Thu, 24 Sep 2009 05:00:50 GMT

> The point of the post is to dispel the conventional wisdom that using try/catch does not impact performance; this shows that it does.

I disagree. This article shows that changing the requirements of a program can result in an implementation that has different performance characteristics. Moving the WriteLine to the finally block means you're comparing apples to oranges; the programs aren't interchangeable implementations of the same spec, one using try/finally and the other not, they implement different specifications.

I mean, it's true that the second program can't be optimized in the same way that the first one can. I think it's invalid to draw general conclusions about that from this example. What if you rewrite it in the style Norman suggests?

re: Performance Implications of try/catch/finally

Chuck — Tue, 22 Sep 2009 05:39:24 GMT

Thanks for appropriately reading thru the typos in my post :)

On further review, I see all that should've been clear, but I thank you also for accommodating me in my paraphrase of your point.

re: Performance Implications of try/catch/finally

PeterRitchie — Sun, 20 Sep 2009 17:14:35 GMT

@Chuck. That's the point; the mere introduction of a try block now means there are three explicit potential outcomes. Previously they where only implicit and could be optimized away because they were implicit. The only difference between the two snippets of code is the try/catch. Thus, "using try/catch does not affect performance" is not true (the point of the post).

re: Performance Implications of try/catch/finally

PeterRitchie — Sun, 20 Sep 2009 17:12:04 GMT

@foobar,that's kind of the point. How do you show how using try/catch affects performance if you don't have "two programs"?

re: Performance Implications of try/catch/finally

Chuck — Sat, 19 Sep 2009 23:28:32 GMT

If I can summarize, I think the criticisms between your non-try code and your try-blocked code is that they're not really functional equivalents. I'm a linguist, not a computer-scientists so I apologize if the jargon is off -- but in the non-try code, the value of the variable inside WriteLine is always 3 regardless of what happens with the other functions being called.

The JIT-compiled code is -- absolutely and of course -- different between the two because the try-blocked code has not one but THREE potential outcomes:

int count = 1;

try

{

SomeMethod(); ## Raise exception here count=1

count++;

SomeOtherMethod(); ## Raise exception here count=3

count++;

}

The functionally-equivalent code, then, is not something that runs two functions and makes count == 3, but rather, the possibility of a raised exception means that there are two implicit conditionals within the try block where there are not within the non-try-block'd code.

So in order to instantiate the conditionals implied within the try block due to the raised exception, you'd have to do something like:

int count = 1;

if someMethod(){

count++

if someOtherMethod(){

count++}

}

Console.WriteLine(count);

I guess I'd be curious to know: is there a performance difference between THAT and the try-finally code?

re: Performance Implications of try/catch/finally

foobar — Sat, 19 Sep 2009 20:54:36 GMT

@Peter The examples are two different programs. They have different outputs depending on when an exception is thrown. They are not the same and thus the optimizations are not the same. If you wanted to point out that similar programs with different output might have different runtime performance, then keep the article. But, it does not prove anything about the lack of optimizations in a try/catch/finally block.

re: Performance Implications of try/catch/finally

PeterRitchie — Sat, 19 Sep 2009 19:50:54 GMT

@Jonathan Allen: In what way do you think this is nonsense?

re: Performance Implications of try/catch/finally

PeterRitchie — Sat, 19 Sep 2009 19:50:32 GMT

@d * @bmm60 Exactly, we don't want it to optimise this code. The point of the post is to dispel the conventional wisdom that using try/catch does not impact performance; this shows that it does.

re: Performance Implications of try/catch/finally

Jonathan Allen — Sat, 19 Sep 2009 18:11:30 GMT

Um, you really should consider removing this post. It would be bad enough if a newbie spouted off such nonsense, but as a MVP it is just disgraceful.

re: Performance Implications of try/catch/finally

Sat, 19 Sep 2009 15:29:05 GMT

Do we want this code optimised, though? The coding suggests that if SomeMethod fails, we want count == 2, and if SomeOtherMethod fails, we want count == 3.

re: Performance Implications of try/catch/finally

bmm6o — Sat, 19 Sep 2009 15:12:18 GMT

It's not just that the jitter doesn't optimize away the count variable entirely, it would be illegal to. It's possible for the output of the second program to be "1", "2" or "3", depending on which (if any) function calls throw an exception. This makes it a fundamentally different program from the first (which will output "3" when it outputs anything). The moral of the story isn't that you should be wary of losing optimization opportunities, it's that you should understand what try/finally does and use it properly.

It would be interesting if there were other *legal* optimizations that aren't made, but your example doesn't show this.

re: Performance Implications of try/catch/finally

PeterRitchie — Fri, 27 Mar 2009 15:02:34 GMT

@Eugen. I prefer returning null for "search-like" method. I would to performance tests specifically in your circumstance; but my tests show that throwing/catching an exception over returning null is only about 5% slower. If you don't plan on throwing many exceptions, the difference is essentially negligible.

re: Performance Implications of try/catch/finally

Eugen — Thu, 26 Mar 2009 23:23:03 GMT

In a business layer where we are searching for records is there much of a performace hit to throw a custom exception like ProductNotonFileException instead of null for example.

re: Performance Implications of try/catch/finally

Esteban Araya — Fri, 24 Oct 2008 03:43:23 GMT

Peter,

Thanks for helping me understand one of the often ignored costs of throwing exceptions. I think too often we ignore the fact that what we write and the bytecode are not exactly the same thing.

re: Performance Implications of try/catch/finally

PeterRitchie — Fri, 03 Oct 2008 14:05:14 GMT

@Norman. Yes, due to various guarantees it has to disable *some* optimizations in the try block.

For example:

try

{

i = 1;

i = 2;

methodThatMightThrow();

i = 3;

Trace.WriteLine(i);

}

catch(Exception)

{

}

Trace.WriteLine(i);

The compiler/runtime guarantees that the state of i will be 2 when the exception is thrown (and that i will be 1 if an exception occurs before setting it to 2--remember there are asynchronous exceptions). Normal optimizations would think that i only ever really needs to be 3 and would optimize as such.

re: Performance Implications of try/catch/finally

Norman Diamond — Fri, 03 Oct 2008 04:45:39 GMT

Theoretically the try part of this try statement doesn't have to disable optimization, but the finally part has to disable (to some extent) optimization of the try part. The reason is that the finally part fetches the value of count.

As an analogy, suppose you compare two programs, one with trivial uses of count the way your first program did, and the other one with a for loop and a call to some function with count as an argument in that function call. Would you say that the for loop causes the decrease in optimization, or would you say that passing count as an argument causes the decrease in optimization?

re: Performance Implications of try/catch/finally

PeterRitchie — Thu, 17 Jan 2008 02:22:52 GMT

Yes, lock uses try/catch, it will have the same performance implications.

re: Performance Implications of try/catch/finally

Jesse — Wed, 16 Jan 2008 20:00:54 GMT

Does this mean that locked code is not optomized? e.g:

Lock(this)

{

SomeMethod();

count++;

SomeOtherMethod();

count++;

Console.WriteLine(count);

}

Exception Logging

Peter Ritchie's MVP Blog — Thu, 02 Aug 2007 02:52:59 GMT

There is often a requirement for an application to log unhandled (and sometimes "handled")