필드 대 실제 성능

Question

나는 어셈블리의 모든 메소드 (즉, 많은 메소드)에 CIL을 추가하는 빌드 후 CIL 제직을하고 있습니다. 각 메소드는 특정 값이 널 (NULL)인지 점검합니다. 예 (CIL 코드의 C# Reflector'd 버전) :

// CIL woven region start 
if (MyType.Something == null) { 
// ... some new stuff 
} 
// CIL woven region end 

하는 Field 대 속성으로 MyType.Something 데의 성능에 미치는 영향은 무엇입니까? 나는 C# 컴파일러가 특별한 최적화를 수행하고 그 경우 성능에 영향을 미치지 않아야한다는 것을 읽었다. 그러나 직접 CIL 코드 (C# 컴파일러가 아닌)의 경우는 어떨까? 또는 이러한 최적화를 허용하는 JIT 컴파일러입니까? (직접 CIL 코드는 여전히 이점이 있습니까?)

정적 속성의 접근 자에 대한 OpCode.Call이 Ldsfld보다 성능이 떨어집니다 (어셈블리의 모든 메서드가 짜여져 있으므로 수만 번의 호출을 염두에 둡니다)?

감사합니다.

Answer 1

SlimDX 용 수학 라이브러리를 개발할 때, 이전 .NET 3.5 SP1 프레임 워크에서 수학 유형의 멤버 (예 : Vector3의 경우 X, Y, Z) 필드를 사용하면 불균형 성능 속성을 늘리십시오. 즉, 속성에 많이 액세스하는 작은 수학 함수에서 차이가 눈에 띄게 나타납니다.

이후 .NET 3.5 SP1 (JIT inling 참조) 이후로 향상되었습니다. 그 이전의 JIT는 여전히 작은 메소드 (속성은 단순히 메소드입니다)를 계속 인라인한다고 믿는 반면, 이전 프레임 워크에서는 값 유형을 사용하거나 반환하는 메소드의 인라이닝을 방지하는 버그가 있습니다.

차이점은 여전히 ​​매우 작습니다. 나는 여전히 가장 중요한 성능의 경우를 제외하고는 모두 속성을 사용하도록 선택했습니다.

Answer 2

C# 컴파일러는이 문제를 최적화하지 않습니다.하지만 JIT 컴파일러는 보통 내가 알고있는 한 사소한 (그리고 가상이 아닌) 속성을 인라인 할 수 있습니다.

모든 성능 질문과 마찬가지로 : 의심 스러울 때 테스트하십시오!

Answer 3

효과는 어느 방향으로나 작습니다. 귀하의 속성이 다음과 같이 보이는 경우 ::

public static SomeType PropertyName 
{ 
    get {return MyType.propertyName;} 
    set {MyType.propertyName = value;} 
} 

진정한 사소한 차이가 있습니다. Jit 컴파일러는 callMyType.set_Property을 필드로드로 인라인해야하지만 버그로 인해 수행 할 수없는 경우에도 마찬가지입니다. 나는 개인적으로주의의 측면에서 실수하고 속성 setter 및 getters 잠재적으로 메서드 본문을 변경할 수 있습니다 및 결과로 원시 필드 액세스/돌연변이 충분하지 않을 수도 있습니다.

테스트하려는 경우 인라이닝 또는 최적화를 해제하는 MethodImpl을 사용하도록 강제로 메소드를 강제 실행할 수 있습니다. 그리고 그 차이를 비교해보십시오, 나는 그것이 그것이 중요 할 것이라는 것을 정말로 의심합니다.