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.
"Pohihihi" <po******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

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) {}

[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/de...etperftips.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.


--
W.G. Ryan MVP (Windows Embedded)

TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"David Levine" <no****************@wi.rr.com> wrote in message
news:en**************@TK2MSFTNGP09.phx.gbl...

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.
"Pohihihi" <po******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I was wondering what is the ill effect of using try catch in the code, bothnested 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]

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" <Wi*********@NoSpam.gmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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/de...etperftips.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.


--
W.G. Ryan MVP (Windows Embedded)

TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"David Levine" <no****************@wi.rr.com> wrote in message
news:en**************@TK2MSFTNGP09.phx.gbl...

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.
"Pohihihi" <po******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

>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) {}
>

[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 ;-)

--
W.G. Ryan, MVP

www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"David Levine" <no****************@wi.rr.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <Wi*********@NoSpam.gmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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/de...etperftips.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.


--
W.G. Ryan MVP (Windows Embedded)

TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"David Levine" <no****************@wi.rr.com> wrote in message
news:en**************@TK2MSFTNGP09.phx.gbl...

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.
"Pohihihi" <po******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
>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]

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.
"W.G. Ryan eMVP" <Wi*********@gmail.com> wrote in message
news:Ou**************@TK2MSFTNGP12.phx.gbl...

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 ;-)

--
W.G. Ryan, MVP

www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"David Levine" <no****************@wi.rr.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <Wi*********@NoSpam.gmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

> 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/de...etperftips.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.
>
>
>
>
> --
> W.G. Ryan MVP (Windows Embedded)
>
> TiBA Solutions
> www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
> "David Levine" <no****************@wi.rr.com> wrote in message
> news:en**************@TK2MSFTNGP09.phx.gbl...
>> 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.
>>
>>
>> "Pohihihi" <po******@hotmail.com> wrote in message
>> news:%2***************@TK2MSFTNGP12.phx.gbl...
>> >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) {}
>> >
>>
>>
>
>

[Jon Skeet [C# MVP]]

David Levine <no****************@wi.rr.com> wrote:

<snip>

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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]]

David Levine <no****************@wi.rr.com> wrote:

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).

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.

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.

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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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::Parse(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.<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[David Levine]

"Jeff Louie" <an*******@devdex.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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.

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 :)

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.