Null 허용 유형에서 C# 'as' 연산자가 'is' 연산자보다 느린 이유는 무엇입니까?

C#의 "as" 연산자 및 Nullable 유형의 예기치 않은 성능 차이

C#의 "as" 연산자는 수행하는 편리한 방법을 제공합니다. 유형을 확인하고 동적으로 캐스트합니다. Null 허용 유형에 "as"를 사용하면 기존의 "is" 연산자 및 캐스팅에 비해 성능이 향상되는 것처럼 보일 수 있지만 최근 테스트에서는 놀라운 결과가 나타났습니다.

객체 배열에 혼합이 포함된 테스트 시나리오에서 정수, 문자열 및 Null 참조 중에서 "as" 연산자는 "is" 연산자에 비해 성능이 크게 저하됩니다. "as" 연산자의 유형 검사와 값 검사 조합이 동적 유형을 두 번 쿼리하는 것보다 더 효율적일 것이라고 가정하기 때문에 이는 예상치 못한 일이었습니다.

null 허용 유형에 대한 "isinst"의 .NET 구현을 분석하면 알 수 있습니다. 특별히 느리지 않다는 것입니다. 대신 문제는 null 허용 유형과 함께 "as"를 사용할 때 필요한 추가 unboxing 단계에서 발생하는 것으로 보입니다.

JIT 컴파일러는 "is" 연산자에 대해 고도로 최적화된 코드를 생성하고 null을 허용하지 않는 유형에 대해 캐스팅할 수 있습니다. 그러나 nullable 유형의 "as"에는 unboxing 및 Nullable로의 변환을 수행하기 위한 더 복잡한 JIT 도우미 함수가 필요합니다. 이 함수는 "is" 연산자에 사용되는 직접 유형 검사 및 캐스팅보다 오버헤드가 높습니다.

"OfType()"과 일반 유형으로의 캐스팅을 사용하는 LINQ 솔루션도 다음보다 성능이 떨어집니다. "is" 연산자입니다. 이는 Nullable로 변환하는 동안 호출되는 JIT 도우미 함수인 JIT_Unbox() 때문일 수 있습니다.

결론적으로 "as" 연산자는 편리한 구문을 제공하지만 항상 그런 것은 아닙니다. nullable 유형으로 작업할 때 최고의 성능을 제공합니다. 성능이 중요한 시나리오에서는 "is" 연산자를 사용하고 원하는 유형으로 직접 캐스트하는 것이 좋습니다.

위 내용은 Null 허용 유형에서 C# 'as' 연산자가 'is' 연산자보다 느린 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!