'as' 연산자는 C#의 Nullable 형식에 대해 항상 'is'보다 성능 이점을 제공합니까?

"as" 연산자와 Nullable 유형을 사용한 놀라운 성능

C# Depth의 4장에서는 Null 허용 유형과 "as" 연산자에 대해 논의합니다. 특히 유형 확인에 "as"를 사용하면 단일 유형 확인 및 값 확인 프로세스가 단순화되므로 기존 "is" 확인 및 캐스팅보다 성능이 향상될 수 있습니다. 그러나 놀라운 결과가 나타났습니다.

성능 벤치마크 테스트

성능을 평가하기 위해 수많은 Null 참조 및 문자열 참조가 포함된 개체 배열 내의 정수를 합산하는 벤치마크 테스트가 수행되었습니다. . 테스트에서는 다음 코드 조각의 실행 시간을 측정했습니다.

• "is" 및 캐스팅
• 을 사용하는 C# 1 스타일 코드 "as" 연산자
• LINQ 솔루션

연구원은 놀랍게도 C# 1 코드가 "as" 코드와 LINQ 코드보다 훨씬 뛰어난 성능을 보였습니다.

결과 분석

성능 불일치의 원인은 다음과 같습니다. 요소:

"is" 및 캐스팅을 위한 JIT 컴파일러 최적화:
"is" 연산자 테스트와 후속 캐스팅은 JIT 컴파일러로 최적화될 수 있으므로 시스템 효율성이 매우 높습니다. 최소한의 명령어로 실행되는 코드입니다. 이러한 최적화는 값 변환이나 복사 없이 boxed 값 유형을 동일한 유형의 변수로 직접 unboxing할 수 있기 때문에 가능합니다.

Nullable로 변환의 복잡성:
int로 캐스팅 하시겠습니까? "as"를 사용하려면 박스형 정수의 값 표현이 Nullable의 메모리 레이아웃과 다르기 때문에 더 복잡한 변환 프로세스가 필요합니다. 이를 위해서는 JIT_Unbox_Nullable이라는 범용 언박싱 도우미 함수가 필요합니다. 이 함수는 일반적인 특성과 유형 검사로 인해 추가 오버헤드를 발생시킵니다.

LINQ의 예기치 않은 동작:
OfType () LINQ의 확장 메서드는 "is" 연산자와 JIT_Unbox() 도우미도 활용합니다. 기능. 그러나 그 성능은 비용이 더 저렴할 것이라는 기대에도 불구하고 Nullable에 대한 "as" 캐스트와 비슷했습니다. 이러한 불일치는 ngen.exe로 인해 발생한 잠재적인 문제 때문일 수 있습니다.

결론

"as" 연산자는 유형 검사 및 null 허용 값 처리를 수행하는 편리한 방법을 제공하지만 성능 특성은 다음과 같습니다. 특정 시나리오가 항상 예상한 것과 다를 수 있습니다. C# 1에서 "is" 및 캐스팅에 대해 생성된 최적화된 코드는 수많은 언박싱 작업이 포함된 경우 훨씬 더 빠르게 유지되므로 코딩 기술을 선택할 때 성능 영향을 고려하는 것이 중요합니다.

위 내용은 'as' 연산자는 C#의 Nullable 형식에 대해 항상 'is'보다 성능 이점을 제공합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!