perf&试着抓 [英] perf & Try Catch

问题描述

我想知道在代码中使用try catch会产生什么不良影响，

嵌套和简单的大问题。


例如

试试

{

\\整个应用程序代码到这里

} catch（例外ee） {}


- 和 -

试试

{

试试

{

try {...} catch（...）{...}

} catch（例外ee）{}

} catch（异常ee）{}

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

推荐答案

这完全取决于代码的作用 - 最终代码必须是

无论性能如何都是正确的，但可能有不同的方法你可以使用b $ b来最大化性能并且仍能得到正确的结果。


那里在设置try-catch块时性能很小，所以如果你在一个循环中你可以通过将for循环包装在一个
$ b $中来获得性能增益。 b try-catch而不是在循环中使用try-catch。但是，如果循环

必须继续枚举项目而不管单个项目被抛出

异常，那么你必须将try-catch放在循环中。捕获异常时，catch块中还有一个小b / b小的命中，因为

运行时必须检查每个catch处理程序以确定它是否适合

处理给定的异常。如果没有处理，异常继续向b / b
传播调用堆栈，但是在使

决定不处理异常时仍然存在非零命中;虽然很小，但并非一无所获。


大部分的性能来自于实际抛出异常，而不仅仅是使用try-catch构造的
，或者只是从捕捉它。在示例

代码中，如果从未抛出异常，则单个

与嵌套try-catch的差异通常是不可察觉的。即使在嵌套的

情况下，如果内部catch处理异常，那么单个与嵌套处理程序之间应该没有必然的差异，因为它只是。


但是，如果内部catch重新抛出异常，那么现在抛出两个

异常，所以性能指数将会更高，大约是b / b
性能的两倍。原因在于，大部分的性能来自于两次走栈的机制，第一次找到一个捕获的

处理程序，第二次来自运行下游终于阻塞之前

执行控制权交给了处理

异常的catch处理程序。第一遍的堆栈遍历实际上是通过

内核转换，进行系统调用以确定是否附加了调试器等。这个

完全是非本地的，所以发生缓存未命中，页面可能会出现故障等待内存等等。每次抛出异常时都会发生这种情况，所以如果你这样做了很多次尝试抓住重新抛出你的表现会降低，人们会在系统预热后以线性方式预期

。


作为双重警告，我认为额外的性能重新抛出异常

来做生意的成本，我会在必要时重新抛出

来添加足够的上下文来使纠正问题变得容易结束

用户尽可能。这是因为一旦你接受了你在
非高效路径中的话，那么额外费用可以忽略不计，相比之下，与最终用户呼叫支持说和相关的费用是相同的。 ;你知道那个错误

消息说''null reference''？是的，那是什么意思呢？
是什么意思？换句话说，我的感觉是清晰度更重要，然后从代码中挤出几克的脂肪。当然，代码的详细信息及其使用方式决定了最终策略和

结构你必须做的事情。


基本上，我使用的策略是永远不会抛出异常，除非有无法处理的

a问题，然后使用try-catch-wrap-rethrow作为

通常在必要时提供上下文;一旦开始

在异常路径下我将额外的性能打击视为次要问题。

Pohihihi < PO ****** @ hotmail.com>在留言中写道

新闻：％2 *************** @ TK2MSFTNGP12.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...

我在想什么是在代码中使用try catch的不良影响，包括嵌套和简单的大问题。

例如

尝试
{
\\整个应用程序代码都在这里
} catch（例外ee）{}

- 和 -
尝试
{
尝试
{
尝试{...} catch（...）{...}
} catch（例外ee）{}
} catch（Exception ee）{}

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

大卫：


不要吝啬但是没有打包只是简单包装

a中的代码尝试捕获
http://msdn.microsoft.com/library/de...etperftips.asp


找到并设计掉异常繁重的代码可能导致dec ent perf

胜利。请记住，这与try / catch块无关：你只需要在抛出实际异常时产生成本。您可以根据需要使用尽可能多的

try / catch块。毫无意义地使用例外情况你会损失性能。例如，你应该远离控制流使用

异常之类的东西。


抛出异常肯定是更令人担忧的问题，你在哪里

应该关注 - 但是你可以把它包裹起来 - 没有任何打击。



-

WG Ryan MVP（Windows Embedded）

TiBA解决方案
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com

" David Levine" <无**************** @ wi.rr.com>在消息中写道

新闻：en ************** @ TK2MSFTNGP09.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...

这完全取决于什么代码确实 - 无论性能如何，最终代码必须是正确的，但是可能有不同的方法可以用来最大化性能并且仍能得到正确的结果。

那里在设置try-catch块时性能很小，所以如果
你处于循环中，你可以通过将for循环包装在一个单独的try-catch而不是使用try-catch在循环中。但是，如果
循环必须继续枚举项目而不管单个项目的抛出异常，那么你必须将try-catch放在循环中。捕获异常时，catch块中还有一个小的perf命中，因为
运行时必须检查每个catch处理程序以确定它是否适合处理给定的异常。如果没有处理，异常继续向上传播调用堆栈，但是在使
决定不处理异常时仍然存在非零命中;很小但并非一无所获。

大多数的性能来自实际抛出异常，而不仅仅是使用try-catch构造，或者仅仅是捕获它。在你拥有的示例代码中，如果永远不会抛出异常，那么
单个与嵌套try-catch的区别通常是不可察觉的。即使在嵌套的
情况下，如果内部catch处理异常，那么单个与嵌套处理程序之间应该没有
性能差异，因为它只被抛出并被捕获一次。 br />
但是，如果内部捕获重新抛出异常，那么现在抛出两个异常，因此性能指数会更高，大约是性能的两倍。原因是大部分的性能来自于堆栈两次走动的机制，第一次找到一个捕获处理器，第二次从下游运行最后阻塞
执行控制是处理处理
异常的catch处理程序。第一遍的堆栈遍历实际上是通过内核转换，进行系统调用以确定是否附加了调试器等。
这完全是非本地的，因此发生缓存未命中，页面可能会出现故障每次抛出异常时都会发生这种情况，所以如果你用
进行大量的try-catch-rethrow，你的性能会降低，人们会期望线性化系统预热后的时尚。

作为一个双重警告，我认为重新抛出
例外的额外性能是开展业务的成本，我会在必要时重新抛出为了使
最终用户更容易纠正问题，为了添加足够的上下文。这是因为一旦你接受了你处于一个非高效的路径，那么与最终用户呼叫支持相关的成本相比，额外的成本可以忽略不计，说你知道错误
消息说''null reference''？是的，那是什么意思？
意味着什么？换句话说，我的感觉是清晰度更重要，然后从代码中挤出几克的脂肪。当然，代码的详细信息及其使用方式决定了最终策略
和你必须做的结构。

基本上，我使用的策略是永远不会抛出一个异常，除非
是一个无法处理的问题，然后经常根据需要使用try-catch-wrap-rethrow来提供必要的上下文;一旦
从异常路径开始，我将额外的性能打击视为一个小问题。

" Pohihihi" < PO ****** @ hotmail.com>在消息中写道
新闻：％2 *************** @ TK2MSFTNGP12.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...

我在想是什么病在代码中使用try catch的效果，
arenested和简单的大的。

例如

尝试
{
\\整个应用程序代码都在这里
} catch（例外ee）{}

- 和 -
尝试
{
尝试
{
尝试{...} catch（...）{...}
} catch（异常ee）{}
} catch（Exception ee）{}

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

嘿，继续挑选 - 这就是我的学习方法。


我读过那篇论文，遗憾的是当你抛出实际的异常时，你只需支付成本

。是完全错误，或充其量，

不完整。异常本身的成本仅在抛出时发生，

但是仍然存在与定义try块相关的成本。


Nick Wienholt'' s书最大化.NET性能有一节关于这一点 - 我

我没有它，否则我会给你直接引用 - 那个细节

简单的一些开销使用try / catch块。按理说

成本是非零 - 必须建立试块，

和成本虽然很小，但仍然不为零，成本将加起来。

每个方法都有一个小的命中（时间和内存），并且有一个

try-catch或try-finally获取JITd（运行时使用它来确定发生异常时哪个
try块有效。）因为必须计算每个代码块的相对

偏移量并且这些区域缓存在

表中。


在大多数情况下，这些命中的性能影响是通过一个很昂贵的b
昂贵的代码路径摊销的所以增量差异是可以忽略不计的。但是，如果

你运行了一个代码执行不多的测试，那么定义一个try块然后

相对影响会更大。


WG Ryan eMVP <无线********* @ NoSpam.gmail.com>在消息中写道

news：％2 **************** @ tk2msftngp13.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：

不要吝啬但是没有打包只需将代码包裹在
中即可尝试捕获
http://msdn.microsoft。 com / library / de ... etperftips.asp

找到并设计出异常繁重的代码可以带来不错的胜利。请记住，这与try / catch块无关：只有在抛出实际异常时才会产生成本。您可以根据需要使用许多
try / catch块。无偿使用例外是您失去性能的地方。例如，你应该远离诸如使用
控制流的例外之类的东西。

抛出异常肯定是更令人担忧的，你应该关注的地方 - - 但你可以随身携带 - 没有任何打击。


- WG Ryan MVP（Windows Embedded）

TiBA解决方案 www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
David Levine <无**************** @ wi.rr.com>在消息中写道
新闻：en ************** @ TK2MSFTNGP09.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...

这完全取决于代码的作用 - 最终，无论性能如何，代码必须是正确的，但是可能有不同的方法可以用来最大化性能并且仍能得到正确的结果。

性能很小点击设置一个try-catch块，所以如果

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

你

在一个循环中你可以通过将for循环包装在
中来获得性能增益。单个
try-catch而不是在循环中使用try-catch。但是，如果

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

循环

必须继续枚举项目而不管单个项目的抛出异常，那么你必须把try-catch放在里面循环。捕获异常时，catch块中还有一个小的perf命中因为
运行时必须检查每个catch处理程序以确定它是否适合
处理给定的异常。如果没有处理，异常继续向上传播调用堆栈，但在

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

决定不处理

时仍然存在非零命中例外;很小但并非一无所获。

大多数的性能来自实际抛出异常，而不仅仅是使用try-catch构造，或者仅仅是捕获它。在
示例代码中，如果永远不会抛出异常，则

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

单个

与嵌套try-catch的区别通常是不可思议即使在嵌套
的情况下，如果内部catch处理异常那么应该没有

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

perf

单个与之间的区别嵌套处理程序，因为它只被抛出并被捕获一次。

然而，如果内部catch重新抛出异常，那么你现在抛出了两个异常，所以perf命中更大，大约两倍的性能。原因是大部分的性能来自于两次走动堆栈的机制，第一次找到一个捕获处理器，第二次从下游运行最终阻止

执行控制之前，处理
异常的catch处理程序。第一遍的堆栈遍历实际上是通过
内核转换，进行系统调用以确定是否附加了调试器等。

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.

这个

完全是非本地的，因此发生缓存未命中，页面可能会出现故障等内存等。每次抛出异常都会发生这种情况，所以如果你

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

做

很多尝试 - 抓住 - 重新抛出你的性能会降低，人们会在系统预热后以线性方式预期


双重警告，我认为重新抛出一个

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

异常

的额外性能将成为开展业务的成本，我将在
顺序中根据需要重新抛出
添加足够的上下文以使问题更容易被

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

结束

用户。这是因为一旦你接受了你处于一个非高效的路径，那么与最终用户呼叫支持相关的成本相比，额外的成本可以忽略不计你知道吗错误
显示''null reference''的消息？是的，那是什么意思？
意味着什么？换句话说，我的感觉是清晰度更重要的是

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

从代码中挤出几克的脂肪。当然，代码的详细信息及其使用方式决定了你必须做的最终策略

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

和

结构。

基本上，我使用的策略是永远不会抛出异常，除非

structure of what you must do.

Basically, the strategy I use is to never throw an exception unless there

是

一个无法处理的问题，然后使用try-catch-wrap-经常需要重新抛出，以尽可能多地提供背景;一旦

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

启动

沿异常路径向下我将额外的性能打击视为次要问题。

Pohihihi < PO ****** @ hotmail.com>在消息中写道
新闻：％2 *************** @ TK2MSFTNGP12.phx.gbl ...

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

>我想知道什么是在代码中使用try catch的不良影响，包括>嵌套和简单的大问题。
>
>例如
>
>试试
> {
>整个应用程序代码都在这里
> } catch（例外ee）{}
>
> - AND -
>试试
> {
>试试
> {
>尝试{...} catch（...）{...}
> } catch（例外ee）{}
> } catch（Exception ee）{}
>

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

这篇关于perf&amp;试着抓的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！