exception은 throw 되었을 때만 성능 저하를 일으킨다.
그 이유중 하나는 stack trace를 위해 rewind 하는 오버헤드가 크기 때문인 것으로 보인다.
따라서 exception을 "exceptional behavior" 에만 사용한다면
try-catch 에서의 성능저하는 없다고 봐도 무방하다.
------------------------
http://stackoverflow.com/questions/52312/what-is-the-real-overhead-of-try-catch-in-c
I'm not an expert in language implementations (so take this with a grain of salt), but I think one of the biggest costs is unwinding the stack and storing it for the stack trace. I suspect this happens only when the exception is thrown (but I don't know), and if so, this would be decently sized hidden cost every time an exception is thrown... so it's not like you are just jumping from one place in the code to another, there is a lot going on.
I don't think it's a problem as long as you are using exceptions for EXCEPTIONAL behavior (so not your typical, expected path through the program).
Firstly, there is little or NO performance penalty in actually having try-catch blocks in your code. This should not be a consideration when trying to avoid having them in your application. The performance hit only comes into play when an exception is thrown.
'C#, .NET' 카테고리의 다른 글
as vs casting (0) | 2011.06.17 |
---|---|
synchronization (0) | 2011.06.17 |
performance 고려사항 (0) | 2011.06.17 |
int to byte[] , byte[] to int (0) | 2011.06.17 |
Form application 과 Thread (0) | 2011.06.17 |