성찰 가속화에 관한 실패한 기사

기사제목을 바로 설명드리겠습니다. 원래 계획은 간단하지만 현실적인 예를 사용하여 리플렉션 사용 속도를 높이는 데 대한 훌륭하고 신뢰할 수 있는 조언을 제공하는 것이었지만 벤치마킹 중에 리플렉션이 생각만큼 느리지 않고 LINQ가 악몽보다 느리다는 사실이 밝혀졌습니다. 하지만 결국 측정에서도 실수를 했다는 사실이 밝혀졌습니다... 이 인생 이야기의 자세한 내용은 컷 아래에 있고 댓글에 있습니다. 이 예는 기업에서 일반적으로 수행되는 것처럼 매우 일반적이고 원칙적으로 구현되기 때문에 제가 보기에는 삶의 시연인 것처럼 매우 흥미로운 것으로 나타났습니다. 기사의 주요 주제의 속도에 미치는 영향은 다음과 같습니다. Moq, Autofac, EF Core 및 기타 "밴딩"과 같은 외부 논리로 인해 눈에 띄지 않습니다.

나는 이 기사의 인상을 받아 작업을 시작했습니다. 반사가 느린 이유

보시다시피 저자는 애플리케이션 속도를 크게 높이는 좋은 방법으로 리플렉션 유형 메서드를 직접 호출하는 대신 컴파일된 대리자를 사용하는 것을 제안합니다. 물론 IL 방출이 있지만 이는 오류가 많은 작업을 수행하는 가장 노동 집약적 방법이기 때문에 피하고 싶습니다.

나는 성찰의 속도에 대해 늘 비슷한 의견을 갖고 있었기 때문에 특별히 저자의 결론에 의문을 제기할 의도는 없었습니다.

나는 종종 기업에서 성찰을 순진하게 사용하는 것을 접합니다. 유형이 사용됩니다. 부동산에 관한 정보가 수집됩니다. SetValue 메서드가 호출되고 모두가 기뻐합니다. 목표 필드에 값이 도착하면 모두가 행복해집니다. 매우 똑똑한 사람들(선배와 팀 리더)은 한 유형의 "범용" 매퍼를 다른 유형으로 순진하게 구현한 것을 기반으로 객체에 대한 확장을 작성합니다. 본질은 일반적으로 다음과 같습니다. 모든 필드를 가져오고, 모든 속성을 가져오고, 반복합니다. 유형 멤버의 이름이 일치하면 SetValue를 실행합니다. 때때로 우리는 유형 중 하나에서 일부 속성을 찾지 못한 실수로 인해 예외를 포착하지만 여기에도 성능을 향상시키는 방법이 있습니다. 시도해 보세요.

나는 사람들이 그들보다 먼저 나온 기계가 어떻게 작동하는지에 대한 정보를 완전히 갖추지 않은 채 파서와 매퍼를 재창조하는 것을 보았습니다. 나는 사람들이 전략 뒤에, 인터페이스 뒤에, 주사 뒤에 자신의 순진한 구현을 숨기는 것을 보았습니다. 마치 이것이 후속적인 금욕증을 용서해 주는 것처럼 말입니다. 나는 그런 깨달음에 고개를 돌렸다. 실제로 실제 성능 누출을 측정하지 않았으며 가능하다면 구현을 손에 넣을 수만 있다면 더 "최적"인 구현으로 변경했습니다. 따라서 아래에서 논의되는 첫 번째 측정은 나를 심각하게 혼란스럽게 했습니다.

Richter나 다른 이데올로기의 글을 읽으면서 많은 분들이 코드에서의 반영은 애플리케이션 성능에 극도로 부정적인 영향을 미치는 현상이라는 완전히 공정한 진술을 접하셨을 것입니다.

리플렉션을 호출하면 CLR이 어셈블리를 거쳐 필요한 것을 찾고, 해당 메타데이터를 가져오고, 구문 분석하는 등의 작업을 수행하게 됩니다. 또한 시퀀스를 순회하는 동안 반영되면 많은 양의 메모리가 할당됩니다. 우리는 메모리를 모두 사용하고 있으며 CLR은 GC를 발견하고 프리즈가 시작됩니다. 눈에 띄게 느려질 것입니다. 제 말을 믿으세요. 최신 프로덕션 서버 또는 클라우드 시스템의 엄청난 양의 메모리는 높은 처리 지연을 방지하지 못합니다. 실제로 메모리가 많을수록 GC 작동 방식을 알아차릴 가능성이 더 높아집니다. 이론적으로 반사는 그에게 여분의 붉은 걸레입니다.

그러나 우리 모두는 IoC 컨테이너와 날짜 매퍼를 사용하며 그 작동 원리도 반사를 기반으로 하지만 일반적으로 성능에 대해서는 의문의 여지가 없습니다. 아니요, 외부 제한된 컨텍스트 모델의 종속성과 추상화를 도입하는 것이 너무 필요해서 어떤 경우에도 성능을 희생해야 하기 때문이 아닙니다. 모든 것이 더 간단해졌습니다. 실제로는 성능에 큰 영향을 미치지 않습니다.

사실 리플렉션 기술을 기반으로 하는 가장 일반적인 프레임워크는 보다 최적으로 작동하기 위해 모든 종류의 트릭을 사용합니다. 일반적으로 이는 캐시입니다. 일반적으로 이는 식 트리에서 컴파일된 식 및 대리자입니다. 동일한 자동 매퍼는 리플렉션을 호출하지 않고 유형을 다른 유형으로 변환할 수 있는 함수와 유형을 일치시키는 경쟁력 있는 사전을 유지 관리합니다.

이것이 어떻게 달성됩니까? 본질적으로 이는 플랫폼 자체가 JIT 코드를 생성하는 데 사용하는 논리와 다르지 않습니다. 메서드가 처음 호출되면 컴파일되고(물론 이 프로세스는 빠르지 않습니다.) 후속 호출에서는 제어가 이미 컴파일된 메서드로 이전되므로 심각한 성능 저하가 발생하지 않습니다.

우리의 경우 JIT 컴파일을 사용한 다음 AOT와 동일한 성능으로 컴파일된 동작을 사용할 수도 있습니다. 이 경우 표현이 도움이 될 것입니다.

문제의 원칙은 다음과 같이 간략하게 공식화될 수 있습니다.
컴파일된 함수를 포함하는 대리자로 리플렉션의 최종 결과를 캐시해야 합니다. 또한 객체 외부에 저장되는 작업자 유형 필드의 유형 정보와 함께 필요한 모든 객체를 캐시하는 것이 좋습니다.

여기에는 논리가 있습니다. 상식에 따르면 컴파일하고 캐시할 수 있는 작업은 수행되어야 합니다.

앞으로는 제안된 표현식 컴파일 방법을 사용하지 않더라도 리플렉션 작업 시 캐시에 장점이 있다고 말해야 합니다. 실제로 여기서는 위에서 언급한 기사 작성자의 논문을 반복하고 있습니다.

이제 코드에 대해 알아보겠습니다. 제가 최근 진지한 신용 기관의 프로덕션에서 직면해야 했던 고통을 바탕으로 한 예를 살펴보겠습니다. 모든 실체는 허구이므로 누구도 추측할 수 없습니다.

본질이 있습니다. 접촉이 있게 하십시오. 파서와 하이드레이터가 동일한 접촉을 생성하는 표준화된 본문을 가진 문자가 있습니다. 편지가 도착하면 우리는 그것을 읽고 키-값 쌍으로 구문 분석하고 연락처를 생성하여 데이터베이스에 저장했습니다.

초등학생입니다. 연락처에 전체 이름, 연령 및 연락처 전화 속성이 있다고 가정해 보겠습니다. 이 데이터는 편지로 전송됩니다. 또한 기업에서는 엔터티 속성을 편지 본문의 쌍으로 매핑하기 위한 새 키를 신속하게 추가할 수 있는 지원을 원합니다. 누군가 템플릿에 오타를 냈거나 출시 전에 새로운 형식에 적응하여 새로운 파트너로부터 매핑을 긴급하게 시작해야 하는 경우. 그런 다음 저렴한 데이터 수정으로 새로운 매핑 상관 관계를 추가할 수 있습니다. 즉, 삶의 예입니다.

우리는 테스트를 구현하고 생성합니다. 공장.

코드는 제공하지 않겠습니다. 소스가 많고 기사 마지막에 있는 링크를 통해 GitHub에서 사용할 수 있습니다. 귀하의 경우에 영향을 미칠 수 있으므로 로드하고 인식할 수 없을 정도로 고문하고 측정할 수 있습니다. 빠른 것으로 예상되는 하이드레이터와 느릴 것으로 예상되는 하이드레이터를 구별하는 두 가지 템플릿 메소드의 코드만 제공하겠습니다.

논리는 다음과 같습니다. 템플릿 메서드는 기본 파서 논리에 의해 생성된 쌍을 받습니다. LINQ 계층은 파서이자 하이드레이터의 기본 논리로, 데이터베이스 컨텍스트에 요청하고 파서의 쌍과 키를 비교합니다(이러한 기능의 경우 비교를 위해 LINQ가 없는 코드가 있습니다). 다음으로 쌍은 기본 수화 방법으로 전달되고 쌍의 값은 엔터티의 해당 속성으로 설정됩니다.

"Fast"(벤치마크에서 Fast라는 접두사):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

보시다시피, setter 속성이 있는 정적 컬렉션, 즉 setter 엔터티를 호출하는 컴파일된 람다가 사용됩니다. 다음 코드로 생성되었습니다.

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

일반적으로 그것은 분명합니다. 속성을 탐색하고 setter를 호출하는 대리자를 만들고 저장합니다. 그러면 필요할 때 전화를 겁니다.

"느림"(벤치마크에서 접두사 느림):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

여기서는 즉시 속성을 우회하고 SetValue를 직접 호출합니다.

명확성과 참고를 위해 상관 쌍의 값을 엔터티 필드에 직접 쓰는 순진한 방법을 구현했습니다. 접두사 – 수동.

이제 BenchmarkDotNet을 사용하여 성능을 살펴보겠습니다. 그리고 갑자기... (스포일러 - 정확한 결과가 아닙니다. 자세한 내용은 아래에 있습니다)

여기서 무엇을 볼 수 있나요? Fast 접두사를 성공적으로 포함하는 방법은 Slow 접두사가 있는 방법보다 거의 모든 단계에서 더 느린 것으로 나타났습니다. 이는 작업 할당과 속도 모두에 해당됩니다. 반면에 가능한 경우 이를 위해 LINQ 메서드를 사용하여 매핑을 아름답고 우아하게 구현하면 생산성이 크게 저하됩니다. 차이점은 순서입니다. 패스 횟수가 달라도 추세는 변하지 않습니다. 유일한 차이점은 규모입니다. LINQ를 사용하면 속도가 4~200배 느려지고 거의 동일한 규모에서 더 많은 쓰레기가 발생합니다.

업데이트]

나는 내 눈을 믿지 않았지만 더 중요한 것은 우리 동료가 내 눈이나 내 코드를 믿지 않았다는 것입니다. 드미트리 티코노프 0x1000000. 내 솔루션을 다시 확인한 후 그는 초기부터 최종까지 구현의 여러 변경 사항으로 인해 내가 놓친 오류를 훌륭하게 발견하고 지적했습니다. Moq 설정에서 발견된 버그를 수정한 후 모든 결과가 제자리에 나타났습니다. 재테스트 결과에 따르면 주요 추세는 변하지 않습니다. 즉, LINQ는 여전히 반영보다 성능에 더 많은 영향을 미칩니다. 하지만 Expression 컴파일 작업이 헛되지 않고 할당 시간과 실행 시간 모두에서 결과가 표시된다는 점은 좋습니다. 정적 필드가 초기화될 때 첫 번째 실행은 "빠른" 방법의 경우 자연스럽게 느려지지만 상황이 달라집니다.

재테스트 결과는 다음과 같습니다.

결론: 기업에서 리플렉션을 사용할 때 특별히 트릭에 의존할 필요는 없습니다. LINQ는 생산성을 더 많이 소모합니다. 그러나 최적화가 필요한 고부하 메서드에서는 이니셜라이저 및 대리자 컴파일러 형식으로 리플렉션을 저장할 수 있으며, 그러면 "빠른" 논리가 제공됩니다. 이렇게 하면 반사의 유연성과 응용 프로그램의 속도를 모두 유지할 수 있습니다.

벤치마크 코드는 여기에서 확인할 수 있습니다. 누구나 내 말을 다시 확인할 수 있습니다.
Habra반사 테스트

추신: 테스트의 코드는 IoC를 사용하고 벤치마크에서는 명시적 구성을 사용합니다. 사실 저는 최종 구현에서 성능에 영향을 미치고 결과를 시끄럽게 만들 수 있는 모든 요소를 ​​제거했습니다.

PPS: 사용자에게 감사드립니다. 드미트리 티코노프 @0x1000000 첫 번째 측정에 영향을 미친 Moq 설정 오류를 발견해 주셔서 감사합니다. 독자 여러분의 카르마가 충분하다면 좋아요를 눌러주세요. 남자는 멈춰서서 책을 읽고, 다시 확인하고 실수를 지적했습니다. 나는 이것이 존경과 동정을 받을 가치가 있다고 생각한다.

PPPS: 스타일과 디자인의 기초를 파악한 세심한 독자에게 감사드립니다. 나는 통일성과 편리함을 추구합니다. 이번 발표의 외교적 측면에서는 아쉬운 점이 많지만, 그 비판도 감안했습니다. 발사체를 요청합니다.

출처 : habr.com