perf & Try Catch

[Pohihihi]

I was wondering what is the ill effect of using try catch in the code, both
nested and simple big one.

e.g.

try
{
\\ whole app code goes here
} catch (Exception ee) {}

-- AND --
try
{
try
{
try{...} catch(...){...}
}catch(Exception ee) {}
} catch (Exception ee) {}

 

[David Levine]

It depends entirely on what the code does - ultimately the code must be
correct regardless of the perf, but there may be different approaches you
can use to maximize perf and still get correct results.

There is a small performance hit in setting up a try-catch block, so if you
are in a loop you can get a perf gain by wrapping the for loop in a single
try-catch instead of using a try-catch inside the loop. However, if the loop
must continue to enumerate the items regardless of a single item's thrown
exception then you must put the try-catch inside the loop. There is also a
small perf hit in the catch block when the exception is caught because the
runtime must examine each catch handler to determine if it is suitable to
handle a given exception. If not handled the exception continues to
propagate up the call stack, but there is still a non-zero hit in making the
decision not to handle the exception; small, but not nothing.

Most of the perf hit comes from actually throwing the exception, not just
from using a try-catch construct, or just from catching it. In the example
code you have, if an exception is never thrown then the difference a single
versus a nested try-catch would usually be unnoticable. Even in the nested
case, if the inner catch handles the exception then there should be no perf
difference between the single vs. the nested handler because it is only
thrown and caught once.

However, if the inner catch rethrows the exception, then you now have two
exceptions thrown, so the perf hit will be greater, approx twice as much
perf hit. The reason is that the majority of the perf hit comes from the
mechanics of walking the stack twice, the first time to locate a catch
handler, and the second time from running downstream finally blocks before
execution control is handed off the catch handler that deals with the
exception. The stack walk on the 1st pass actually transitions through the
kernel, makes system calls to determine if a debugger is attached, etc. This
is entirely non-local, so cache misses occur, pages may get faulted into
memory, etc. This can happen each time an exception is thrown, so if you do
a lot of try-catch-rethrow your performance will degrade, one would expect
in a linear fashion after the system has warmed up.

As a double-caveat, I regard the extra perf hit from rethrowing an exception
to be the cost of doing business, and I will rethrow as necessary in order
to add sufficient context to make correcting the problem as easy for the end
user as possible. This is because once you accept that you are in a
non-performant path then the extra cost is negligible compared to the cost
associated with an end user calling support saying "you know that error
message that says 'null reference'? Yeah, well, what the heck does that
mean?". In other words, my feeling is that clarity is more important then a
squeezing a few grams of perf fat out of the code. Of course, the
particulars of the code and how it is used dictate the ultimate strategy and
structure of what you must do.

Basically, the strategy I use is to never throw an exception unless there is
a problem that cannot be handled, and then use try-catch-wrap-rethrow as
often as necessary to provide context as much as is necessary; once started
down the exception path I regard the extra perf hit as a minor issue.

 

[W.G. Ryan eMVP]

David:

Don't mean to nitpick but there isn't a hit with simply wrapping the code in
a try catch
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp

"Finding and designing away exception-heavy code can result in a decent perf
win. Bear in mind that this has nothing to do with try/catch blocks: you
only incur the cost when the actual exception is thrown. You can use as many
try/catch blocks as you want. Using exceptions gratuitously is where you
lose performance. For example, you should stay away from things like using
exceptions for control flow."

Throwing the exception is definitely of much more concern and where you
should be concerned -- but you can wrap away - no hit there whatsoever.

 

[David Levine]

Hey, go ahead and pick away - that's how I learn.

I'd read that paper and unfortunately the statement "you only incur the cost
when the actual exception is thrown" is simply wrong, or at best,
incomplete. The cost of the exception itself only occurs when it is thrown,
but there is still a cost associated with defining a try block.

Nick Wienholt's book "Maximising .NET Performance" has a section on this - I
don't have it with me otherwise I'd give you the direct quote - that details
some of the overhead of simply using a try/catch block. It stands to reason
that the cost would be non-zero - something has to establish the try blocks,
and the cost, though small, is still non-zero, and the costs will add up.
There's also a small hit (both time and memory) as each method with a
try-catch or try-finally gets JITd (the runtime uses this to determine which
try block is in effect when an exception occurs.) because the relative
offsets of each code block must be calculated and these regions cached in a
table.

In most cases the perf impact of these hits are amortized over a much
costlier code path so the incremental difference is negligble. However, if
you ran a test where the code did little more then define a try block then
the relative impact would be greater.

 

[W.G. Ryan eMVP]

I'd be intersted in reading that b/c I've seen quite a bit that contradicts
that - not to say what I've come across is correct. Probably a good thing
to test in depth tonight ;-)

 

[David Levine]

Ok, I dug out the book and reread the section on exceptions. Here's a direct
quote:

pg 124: "...making a block of code protected is not overly expensive. For a
simplified test method that assigns new values to elements in a character
array...adding a try-catch block in C# increases execution time by 30
percent. For a try-finally block, execution time is increased by 39 percent.
As the complexity of a method increases, the addition of protected code
blocks becomes less and less significant, but setting up protected code
blocks inside loops should be avoided..."

In other words, for performance this form:
try{ foreach (int i in _arr) { /*some processing*/ } } catch (Exception)
{ }

is preferred over...
foreach (int i in _arr) { try { /* some processing*/ } catch(Exception){} }

Now, there are a lot of unanswered questions that the author does not go
into, such as why the difference in performance between a try-catch versus a
try-finally. I can see why there'd be a onetime perf hit due to the extra
complexity the JIT has to deal with, but it's not clear exactly why there's
an extra runtime hit and where it occurs. I think you'd have to do a deep
dive into the Mono source code to see what code is being executed behind the
scenes to fully understand it, and I don't know how much help it would be,
except in the most general way, because the Mono implementation is different
from the commercial implementation.

If my memory is correct, from what I've read the CLR doesn't setup a stack
frame for each protected block - I think there's only one per thread which
wraps the entire thread, and then the exception info tables are used to
determine where the handler is located - so it shouldn't need to continually
push and pop stack register values into the fs register, so the extra time
isn't consumed with that.

What I think happens is that when a try block is entered some CLR
housekeeping microcode (for want of a better term) is executed, and the same
when a catch and a finally block are entered - this may be where the
additional execution time comes from.

 

[Jon Skeet [C# MVP]]

What I think happens is that when a try block is entered some CLR
housekeeping microcode (for want of a better term) is executed, and the same
when a catch and a finally block are entered - this may be where the
additional execution time comes from.

Having had a look at the JITted code, I think it's more a case of the
JIT not being able to optimise as heavily, not being able to enregister
as much.

Personally I think that apart from a very, *very* few situations,
exception handling should be implemented according to elegant design
rather than optimal performance. In the case we're talking about, the
processing within the loop would have to be *very* simple for the cost
of adding the try/catch to end up being particularly significant.

 

[David Levine]

Having had a look at the JITted code, I think it's more a case of the
JIT not being able to optimise as heavily, not being able to enregister
as much.

There may be additional housekeeping that isn't obvious just from the JITted
code. Also, did you compile with debug or release settings? (it could make a
difference in how aggressive the optimizations are).

Personally I think that apart from a very, *very* few situations,
exception handling should be implemented according to elegant design
rather than optimal performance. In the case we're talking about, the
processing within the loop would have to be *very* simple for the cost
of adding the try/catch to end up being particularly significant.

I agree completely - design for correctness first, then go back and look at
optimizations as needed. However, this only came up because a statement was
made that there was no cost at all to using a try block, and that statement,
as far as I can tell, is false.

 

[Jon Skeet [C# MVP]]

There may be additional housekeeping that isn't obvious just from the JITted
code. Also, did you compile with debug or release settings? (it could make a
difference in how aggressive the optimizations are).

I compiled without any specific optimisation or debug settings (just
the default) which I believe isn't particularly optimised, but doesn't
have debug information either.

I agree completely - design for correctness first, then go back and look at
optimizations as needed. However, this only came up because a statement was
made that there was no cost at all to using a try block, and that statement,
as far as I can tell, is false.

Agreed. I think I'd say "virtually no cost" to give an appropriate
impression of how small it is in comparison with almost any other
performance penalties, but it's non-zero. At least, it is in some
cases... it could well be that if the JIT is already hampered by other
characteristics of the method, there really *is* no cost. That's a bit
more than I'm willing to investigate atm

 

[Jeff Louie]

David... A try catch finally decomposes into a nested try catch so I
would
assume try catch finally should have a greater overhead than try catch.
Hand
coded try catch written in IL assembler looks like this.

.try // get user input
{
ldstr "Enter number: "
call void
[mscorlib]System.Console::Write(string)
call string [mscorlib]System.Console::ReadLine()
call int32 [mscorlib]System.Int32:arse(string)
// parse may throw exception
stloc.1 // place valid user input into n_input
leave.s got_value // leave don't branch from
try
} // end .try
catch [mscorlib]System.Object
{
pop // remove exception from stack
ldstr "Invalid Number."
call void
[mscorlib]System.Console::WriteLine(string)
leave exit // invalid input so exit program
} // end handler

Regards,
Jeff

Now, there are a lot of unanswered questions that the author does not

go
into, such as why the difference in performance between a try-catch
versus a
try-finally.<

 

[David Levine]

David... A try catch finally decomposes into a nested try catch so I
would assume try catch finally should have a greater overhead than try
catch.

That's true, but you can have a try-catch or a try-finally block - you don't
need a catch statement just to have a finally and vice-versa. The question
was about the overhead associated with simply adding a try-catch or a
try-finally block, not what the performance would be if an exception were
thrown. Also, your example does not have a finally block in it.

 

[David Levine]

I compiled without any specific optimisation or debug settings (just

the default) which I believe isn't particularly optimised, but doesn't
have debug information either.

I would expect that the release version would do more aggressive
optimizations but I could well be wrong. Since it compiles to IL rather then
machine code it's harder for me to make the connection between the degree of
optimization and the resulting machine code.

Agreed. I think I'd say "virtually no cost" to give an appropriate
impression of how small it is in comparison with almost any other
performance penalties, but it's non-zero. At least, it is in some
cases... it could well be that if the JIT is already hampered by other
characteristics of the method, there really *is* no cost. That's a bit
more than I'm willing to investigate atm

That's the way I felt about it. My motto is: a difference that makes no
difference is no difference

I wish I had spent the time to digest the rotor sources - I think it would
shed some insight into this. Ah well, I'll add that to me TODO list.