Re: perf & Try Catch

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: David Levine (noSpamdlevineNNTP2_at_wi.rr.com)
Date: 12/29/04 

Date: Wed, 29 Dec 2004 05:25:27 -0600

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" <WilliamRyan@NoSpam.gmail.com> wrote in message
news:%23P2GFoV7EHA.1396@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/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.
>
>
>
>
> --
> W.G. Ryan MVP (Windows Embedded)
>
> TiBA Solutions
> www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
> "David Levine" <noSpamdlevineNNTP2@wi.rr.com> wrote in message
> news:en78jkR7EHA.2592@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" <pohihihi@hotmail.com> wrote in message
>> news:%23TlMFJR7EHA.208@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) {}
>> >
>>
>>
>
>

Relevant Pages

  • Re: perf & Try Catch
    ... The cost of the exception itself only occurs when it is ... > try-catch or try-finally gets JITd (the runtime uses this to determine ... >>> small perf hit in the catch block when the exception is caught because ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: perf & Try Catch
    ... can use to maximize perf and still get correct results. ... There is a small performance hit in setting up a try-catch block, ... exception then you must put the try-catch inside the loop. ... Most of the perf hit comes from actually throwing the exception, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java Exceptions cause performance hit?
    ... In your comparison the number of iterations ... > compared to the cost of creating and throwing the exception. ... enables.So why does hasNext() exist? ...
    (comp.lang.java.programmer)
  • Re: when to use component-based design vs. stayign with traditional OOP
    ... IOW, in both cases reuse is enabled by cohesion, encapsulation, and capturing invariants. ... When should a standard OOA/D construction approach be used vs. a component-based construction approach? ... throwing an exception? ... How much testing you do depends on your company's business model (i.e., the trade-off between cost of testing and cost of escapes). ...
    (comp.object)
  • Re: perf & Try Catch
    ... Throwing the exception is definitely of much more concern and where you ... should be concerned -- but you can wrap away - no hit there whatsoever. ... > try-catch instead of using a 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 ...
    (microsoft.public.dotnet.languages.csharp)