try-catch의 영향을 테스트하기 위해 몇 가지 코드를 작성했지만 놀라운 결과가 나타났습니다.
static void Main(string[] args)
{
Thread.CurrentThread.Priority = ThreadPriority.Highest;
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;
long start = 0, stop = 0, elapsed = 0;
double avg = 0.0;
long temp = Fibo(1);
for (int i = 1; i < 100000000; i++)
{
start = Stopwatch.GetTimestamp();
temp = Fibo(100);
stop = Stopwatch.GetTimestamp();
elapsed = stop - start;
avg = avg + ((double)elapsed - avg) / i;
}
Console.WriteLine("Elapsed: " + avg);
Console.ReadKey();
}
static long Fibo(int n)
{
long n1 = 0, n2 = 1, fibo = 0;
n++;
for (int i = 1; i < n; i++)
{
n1 = n2;
n2 = fibo;
fibo = n1 + n2;
}
return fibo;
}내 컴퓨터에서는 약 0.96의 값을 일관되게 인쇄합니다.
try-catch 블록으로 Fibo () 내부에 for 루프를 래핑하면 다음과 같습니다.
static long Fibo(int n)
{
long n1 = 0, n2 = 1, fibo = 0;
n++;
try
{
for (int i = 1; i < n; i++)
{
n1 = n2;
n2 = fibo;
fibo = n1 + n2;
}
}
catch {}
return fibo;
}이제 지속적으로 0.69를 인쇄합니다. 실제로 실제로 더 빠르게 실행됩니다! 그런데 왜?
참고 : 릴리스 구성을 사용하여 이것을 컴파일하고 EXE 파일 (Visual Studio 외부)을 직접 실행했습니다.
편집 : Jon Skeet의 우수한 분석 에 따르면 try-catch는 x86 CLR 이이 특정 경우에 CPU 레지스터를 더 유리한 방식으로 사용하게합니다 (그리고 우리는 아직 이유를 아직 이해하지 못했다고 생각합니다). Jon은 x64 CLR에 이러한 차이가 없으며 x86 CLR보다 빠르다는 사실을 확인했습니다. 또한 int유형 대신 Fibo 메서드 내부의 유형을 사용하여 테스트 long한 다음 x86 CLR이 x64 CLR과 마찬가지로 빠릅니다.
업데이트 : 이 문제는 Roslyn에 의해 수정 된 것으로 보입니다. 동일한 컴퓨터, 동일한 CLR 버전-VS 2013으로 컴파일 할 때 위와 같이 문제가 유지되지만 VS 2015로 컴파일하면 문제가 사라집니다.
111
@Lloyd 그는 "실제로 더 빠르게 실행됩니다! 그러나 왜?"
—
Andreas Niedermair
따라서 "예외 삼키기"는 나쁜 습관에서 좋은 성능 최적화로 넘어갔습니다. : P
—
Luciano
이것은 체크되지 않은 또는 체크 된 산술 컨텍스트에 있습니까?
—
Random832
@ taras.roshko : Eric에게 서비스를 중단하고 싶지는 않지만 이것은 실제로 C # 질문이 아닙니다. JIT 컴파일러 질문입니다. 궁극적 인 어려움은 수행과 같이 x86 JIT는 시도 / 캐치없이 많은 레지스터로 사용하지 않는 이유를 노력 과 은 try / catch 블록.
—
Jon Skeet
달콤합니다. 이러한 시도를 중첩하면 더 빨리 갈 수 있습니까?
—
척 Pinkert