try-catch가 프로그램 성능에 영향을 미치나요?

Try-Catch가 실제로 프로그램 성능에 영향을 미치나요?
오늘 저는 코드를 아름답게 만들기 위해 이 메서드의 모든 코드를 try-catch에 넣을지 여부에 대해 TL과 논쟁을 벌였습니다. , 당연히 이의가 있지만 try-catch의 구현 메커니즘을 깊이 연구하지 않았으며 설득력 있는 이유를 제시할 수 없습니다. 오늘 인터넷에서 .net try-catch 분석을 발견하여 공유하겠습니다. with you
많은 게시물에서 Try-Catch의 메커니즘과 성능에 미치는 영향을 분석했습니다.
하지만 Try-Catch가 특히 호스팅 환경에서 시스템 성능을 너무 많이 소모한다는 증거는 없습니다. 정원에 있던 한 네티즌이 StopWatch를 사용해 Try-Catch가 없는 코드와 다른 상황에서 Try-Catch의 코드 실행 시간 표시기를 분석했는데 결과가 크게 다르지 않았던 기억이 납니다.
IL을 기반으로 Try-Catch를 분석해 보겠습니다.
● 메커니즘 분석
.Net의 기본 예외 캡처 및 처리 메커니즘은 각각 예외 모니터링, 캡처 및 처리를 완료하는 try...catch...finally 블록으로 완성됩니다. try 블록은 0개 이상의 catch 블록에 해당할 수 있으며 0개 또는 1개의 finally 블록에 해당할 수 있습니다. 그러나 catch가 없는 시도는 의미가 없어 보입니다. try가 여러 catch에 해당하는 경우 예외가 감지된 후 CLR은 catch 블록의 코드를 위에서 아래로 검색하고 예외 필터를 통해 해당 예외를 필터링합니다. 해당 예외가 발견되지 않으면 CLR은 호출 스택을 따라 더 높은 수준의 일치하는 예외를 검색합니다. 해당 예외가 여전히 스택 상단에서 발견되지 않으면 이때 처리되지 않은 예외가 발생합니다. catch 블록은 실행되지 않습니다. 따라서 try에 가장 가까운 catch 블록이 먼저 통과됩니다.
다음 코드가 있는 경우:
try
{
Convert.ToInt32("Try")
}
catch (FormatException ex1)
{
string CatchFor matException = "CatchFormatException"
}
catch(NullReferenceException ex2)
{
string CatchNullReferenceException = "CatchNullReferenceException"
}
finally
{
string finally = "Finally ";
}
해당 IL은 다음과 같습니다.
.method private hidebysig instance void Form1_Load(object sender,
class [mscorlib]System.EventArgs e) cil Managed
{
// 코드 크기 53(0x35)
.maxstack 1
.locals init ([0] class [mscorlib]System.FormatException ex1,
[1] string CatchFormatException,
[ 2] class [mscorlib] System.NullReferenceException ex2,
[3] string CatchNullReferenceException,
[4] string 마지막으로)
IL_0000: nop
IL_0001: nop
IL_0002: ldstr "Try"
IL_0007: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_000c: pop
IL_000d: nop
IL_000e: Leave.s IL_0026
IL_0010: stloc.0
IL_0011: nop
IL_0012: ldstr "CatchFormatException"
IL_0017: stloc.1
IL_0018: nop
IL_0019: Leave.s IL_0026
IL_001b: stloc.2
IL_001c: nop il_0022 : stloc.3 IL_0023 : nop IL_0024 : Leave.s IL_0026 IL_0026 : nop IL_002A: LDSTR "Finally"
IL_002F: Stloc.s finally
IL_0031: NOP
IL_0032: Endfinally
IL_0033: NOP
IL_0034: RET
IL_0035:
// EX 수신 횟수 3
.try IL_0001 ~ IL_0010 catch [mscorlib]System.FormatException handler IL_0010 ~ IL_001b
.try IL_0001 ~ IL_0010 catch [mscorlib]System.NullReferenceException handler IL_001b ~ IL_0026
.try IL_0001 to IL_0 029 finally handler IL_0029 to IL_0033
} // 메서드 끝 Form1::Form1_Load
코드의 마지막 몇 줄은 IL이 예외 처리를 처리하는 방법을 보여줍니다. 마지막 세 줄의 각 항목을 Exception Handing Clause라고 하며, EHC는 Exception Handing Table을 구성하며, EHT는 ret return 명령어에 의해 일반 코드와 구분됩니다.
EHT에서는 FormatException이 1위임을 알 수 있습니다.
코드가 성공적으로 실행되거나 그 반대로 실행되면 CLR은 EHT를 통과합니다.
1. 예외가 발생하면 CLR은 예외를 발생시킨 코드의 "주소"를 기반으로 해당 EHC를 찾습니다(IL_0001~IL_0010은 감지 코드의 범위입니다). EHC 및 FormatException이 먼저 통과되어 적합한 EHC입니다.
2. 반환된 코드 주소가 IL_0001~IL_0029 내에 있으면 코드 실행 성공 여부에 관계없이 finally 핸들러, 즉 IL_0029~IL_0033에 있는 코드도 실행됩니다.
실제로 catch 및 finally의 순회 작업은 별도로 수행됩니다. 위에서 언급한 것처럼 CLR이 가장 먼저 수행하는 작업은 적절한 catch 블록을 찾으면 해당 finally를 순회하는 것입니다. 이 프로세스는 재귀적입니다. 컴파일러는 C#의 try...catch...finally를 IL의 두 가지 중첩 수준으로 변환하므로 이 작업을 최소한 두 번 수행합니다.
물론, 해당 catch 블록을 찾을 수 없으면 CLR은 finally를 직접 실행한 다음 모든 스레드를 즉시 중단합니다. finally 블록의 코드는 try가 예외를 감지하는지 여부에 관계없이 확실히 실행됩니다.
● 개선 제안
위에서 결론을 내릴 수 있습니다.
"Try-Catch"를 사용하고 예외가 catch된 경우 CLR이 수행하는 모든 작업은 예외 처리 테이블의 Catch 항목을 순회하는 것입니다. 그런 다음 다시 예외 처리 테이블의 finally 항목을 순회할 때 예외 처리 테이블을 순회하는 데 거의 모든 시간이 소요되며 예외가 발견되지 않으면 CLR은 예외 처리 테이블의 finally 항목만 순회하며 필요한 시간은 다음과 같습니다. 최소한.
"Try-Catch" 통과 후 해당 작업을 실행하는 데 걸리는 시간은 특정 코드에 따라 결정됩니다. "Try-Catch"는 모니터링 및 트리거링만 발생시키며 이 부분의 코드 시간은 계산되지 않습니다. "시도"-캐치"소비.
따라서 성능과 코드 검토를 모두 고려할 수 있으며 일반적으로 다음 지침이 권장됩니다.
1. CLR에 명확한 예외 정보를 제공하고 예외를 필터링하는 데 Exception을 사용하지 마세요.
2. 루프에 try...catch를 작성하세요
3. 가능한 적은 코드를 시도하고, 필요한 경우 여러 개의 catch 블록을 사용하고, try에 가장 가까운 위치에 발생할 가능성이 가장 높은 예외 유형을 작성하세요
4. Don Exception 객체를 처리하지 않고 선언하는 것만으로는 충분하지 않습니다. 그렇게 하면 예외 처리 테이블의 길이가 늘어납니다.
5. 성능 카운터 유틸리티의 "CLR Exceptions"를 사용하여 예외를 감지하고 적절하게 최적화합니다
6. 구성원의 Try-Parse 모드를 사용하고, 예외가 발생하면 이를 false로 바꿉니다
결론, Try-Catch는 약간의 시간이 소요되지만 프로그래머는 이에 대해 말할 필요가 없습니다. 위의 분석을 통해 "Try-Catch"가 성능을 잃거나 영향을 미칠 정도는 아닙니다. Catch"는 다른 코드와 동일하며 성능만 중요합니다. 일반 소비자이지만 코드 작성 리뷰를 위해 "Try-Catch"에 주의를 기울이도록 최선을 다해야 합니다.