Re: perf & Try Catch
From: W.G. Ryan eMVP (WilliamRyan_at_gmail.com)
Date: 12/29/04
- Next message: Mel Weaver: "Re: Loading data from Access table to datatable very slow!"
- Previous message: W.G. Ryan eMVP: "Re: Problem updating dataset to database"
- In reply to: David Levine: "Re: perf & Try Catch"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 29 Dec 2004 17:39:45 -0500
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" <noSpamdlevineNNTP2@wi.rr.com> wrote in message news:%23FMJRkZ7EHA.2608@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" <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) {} > >> > > >> > >> > > > > > >
- Next message: Mel Weaver: "Re: Loading data from Access table to datatable very slow!"
- Previous message: W.G. Ryan eMVP: "Re: Problem updating dataset to database"
- In reply to: David Levine: "Re: perf & Try Catch"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
