.NET Core의 성능

.NET Core의 성능

안녕하세요 여러분! 이 글은 동료들과 제가 오랫동안 다양한 프로젝트를 진행하면서 사용해 온 모범 사례 모음입니다.

계산이 수행된 기계에 대한 정보:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz(Kaby Lake R), CPU 1개, 논리 코어 8개 및 물리 코어 4개
.NET 코어 SDK=3.0.100
[호스트]: .NET Core 2.2.7(CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64비트 RyuJIT
코어: .NET Core 2.2.7(CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64비트 RyuJIT
[호스트]: .NET Core 3.0.0(CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64비트 RyuJIT
코어: .NET Core 3.0.0(CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64비트 RyuJIT

작업=코어 런타임=코어

ToList와 ToArray 및 사이클

.NET Core 3.0 출시와 함께 이런 정보를 준비하려고 했는데, 너무 이기더라구요. 남의 영광을 훔치고 남의 정보를 베끼고 싶지 않으니 참고만 할게요. 비교가 자세히 설명되어 있는 좋은 기사 링크.

나 자신을 대신하여 나는 단지 내 측정과 결과를 여러분에게 보여주고 싶을 뿐이며, 루프 작성의 "C++ 스타일"을 좋아하는 사람들을 위해 역방향 루프를 추가했습니다.

암호:

public class Bench
    {
        private List<int> _list;
        private int[] _array;

        [Params(100000, 10000000)] public int N;

        [GlobalSetup]
        public void Setup()
        {
            const int MIN = 1;
            const int MAX = 10;
            Random random = new Random();
            _list = Enumerable.Repeat(0, N).Select(i => random.Next(MIN, MAX)).ToList();
            _array = _list.ToArray();
        }

        [Benchmark]
        public int ForList()
        {
            int total = 0;
            for (int i = 0; i < _list.Count; i++)
            {
                total += _list[i];
            }

            return total;
        }
        
        [Benchmark]
        public int ForListFromEnd()
        {
            int total = 0;t
            for (int i = _list.Count-1; i > 0; i--)
            {
                total += _list[i];
            }

            return total;
        }

        [Benchmark]
        public int ForeachList()
        {
            int total = 0;
            foreach (int i in _list)
            {
                total += i;
            }

            return total;
        }

        [Benchmark]
        public int ForeachArray()
        {
            int total = 0;
            foreach (int i in _array)
            {
                total += i;
            }

            return total;
        }

        [Benchmark]
        public int ForArray()
        {
            int total = 0;
            for (int i = 0; i < _array.Length; i++)
            {
                total += _array[i];
            }

            return total;
        }
        
        [Benchmark]
        public int ForArrayFromEnd()
        {
            int total = 0;
            for (int i = _array.Length-1; i > 0; i--)
            {
                total += _array[i];
            }

            return total;
        }
    }

.NET Core 2.2와 3.0의 성능 속도는 거의 동일합니다. .NET Core 3.0에서 얻을 수 있는 기능은 다음과 같습니다.

내부 최적화 및 명시적인 컬렉션 크기 할당으로 인해 배열 컬렉션의 반복 처리가 더 빠르다는 결론을 내릴 수 있습니다. 또한 목록 컬렉션에는 고유한 장점이 있으므로 필요한 계산에 따라 올바른 컬렉션을 사용해야 한다는 점을 기억할 가치가 있습니다. 루프 작업을 위한 로직을 작성하더라도 이것이 일반적인 루프이며 루프 최적화가 가능하다는 점을 잊지 마십시오. 꽤 오래 전에 habr에 기사가 게재되었습니다. https://habr.com/ru/post/124910/. 여전히 관련성이 있으며 읽기를 권장합니다.

던지다

XNUMX년 전, 저는 레거시 프로젝트를 진행하는 회사에서 일했습니다. 해당 프로젝트에서는 try-catch-throw 구성을 통해 필드 검증을 처리하는 것이 일반적이었습니다. 나는 이것이 프로젝트에 대한 건전하지 못한 비즈니스 논리라는 것을 이미 알고 있었기 때문에 가능할 때마다 그러한 디자인을 사용하지 않으려고 노력했습니다. 하지만 그러한 구성으로 오류를 처리하는 접근 방식이 왜 나쁜지 알아 보겠습니다. 두 가지 접근 방식을 비교하기 위해 작은 코드를 작성하고 각 옵션에 대한 벤치마크를 만들었습니다.

암호:

        public bool ContainsHash()
        {
            bool result = false;
            foreach (var file in _files)
            {
                var extension = Path.GetExtension(file);
                if (_hash.Contains(extension))
                    result = true;
            }

            return result;
        }

        public bool ContainsHashTryCatch()
        {
            bool result = false;
            try
            {
                foreach (var file in _files)
                {
                    var extension = Path.GetExtension(file);
                    if (_hash.Contains(extension))
                        result = true;
                }
                
                if(!result) 
                    throw new Exception("false");
            }
            catch (Exception e)
            {
                result = false;
            }

            return result;
        }

.NET Core 3.0 및 Core 2.2의 결과는 비슷합니다(.NET Core 3.0).

Try catch를 사용하면 코드를 이해하기가 더 어려워지고 프로그램 실행 시간이 늘어납니다. 그러나 이 구성이 필요한 경우 오류를 처리할 것으로 예상되지 않는 코드 줄을 삽입하면 안 됩니다. 이렇게 하면 코드를 더 쉽게 이해할 수 있습니다. 실제로 시스템을 로드하는 것은 예외 처리가 아니라 새로운 예외 생성 구문을 통해 오류 자체를 발생시키는 것입니다.

예외를 던지는 것은 필요한 형식으로 오류를 수집하는 일부 클래스보다 느립니다. 양식이나 일부 데이터를 처리 중이고 오류가 무엇인지 명확하게 알고 있다면 처리해 보는 것은 어떨까요?

이 상황이 예외가 아닌 경우 throw new Exception() 구문을 작성하면 안 됩니다. 예외를 처리하고 던지는 것은 매우 비쌉니다!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

5년 동안 .NET 플랫폼에서 작업하면서 문자열 일치를 사용하는 많은 프로젝트를 접했습니다. 또한 다음 그림도 보았습니다. 여러 프로젝트가 포함된 하나의 엔터프라이즈 솔루션이 있었고 각 프로젝트는 문자열 비교를 다르게 수행했습니다. 그런데 무엇을 사용해야 하며 어떻게 통합해야 할까요? Richter의 C#을 통한 CLR 책에서 ToUpperInvariant() 메서드가 ToLowerInvariant()보다 빠르다는 정보를 읽었습니다.

책에서 발췌:

물론 나는 그것을 믿지 않았고 .NET Framework에서 몇 가지 테스트를 실행하기로 결정했으며 그 결과는 충격적이었습니다. 성능이 15% 이상 향상되었습니다. 그리고 다음날 아침 출근하자마자 이 측정값을 상사에게 보여주고 소스 코드에 대한 액세스 권한을 부여했습니다. 이후 2개의 프로젝트 중 14개의 프로젝트가 새로운 측정을 수용하기 위해 변경되었으며, 이 두 프로젝트가 거대한 Excel 테이블을 처리하기 위해 존재했다는 점을 고려하면 제품에 있어서는 그 결과가 훨씬 컸습니다.

또한 여러분 각자가 가장 최적의 솔루션을 선택할 수 있도록 다양한 버전의 .NET Core에 대한 측정값도 제시합니다. 그리고 제가 일하는 회사에서는 ToUpper()를 사용하여 문자열을 비교한다는 점을 추가하고 싶습니다.

암호:

public const string defaultString =  "VXTDuob5YhummuDq1PPXOHE4PbrRjYfBjcHdFs8UcKSAHOCGievbUItWhU3ovCmRALgdZUG1CB0sQ4iMj8Z1ZfkML2owvfkOKxBCoFUAN4VLd4I8ietmlsS5PtdQEn6zEgy1uCVZXiXuubd0xM5ONVZBqDu6nOVq1GQloEjeRN8jXrj0MVUexB9aIECs7caKGddpuut3";

        [Benchmark]
        public bool ToLower()
        {
            return defaultString.ToLower() == defaultString.ToLower();
        }

        [Benchmark]
        public bool ToLowerInvariant()
        {
            return defaultString.ToLowerInvariant() == defaultString.ToLowerInvariant();
        }

        [Benchmark]
        public bool ToUpper()
        {
            return defaultString.ToUpper() == defaultString.ToUpper();
        }

        [Benchmark]
        public bool ToUpperInvariant()
        {
            return defaultString.ToUpperInvariant() == defaultString.ToUpperInvariant();
        }

.NET Core 3.0에서 이러한 각 메서드의 증가는 ~x2이며 구현 간의 균형을 유지합니다.

계층 컴파일

지난 기사에서 이 기능에 대해 간략하게 설명했는데, 내용을 수정하고 보완하고 싶습니다. 다중 레벨 컴파일은 솔루션의 시작 시간을 단축하지만 코드의 일부가 백그라운드에서 보다 최적화된 버전으로 컴파일되므로 약간의 오버헤드가 발생할 수 있습니다. NET Core 3.0의 출현으로 계층 컴파일이 활성화된 프로젝트의 빌드 시간이 단축되었으며 이 기술과 관련된 버그가 수정되었습니다. 이전에는 이 기술로 인해 ASP.NET Core의 첫 번째 요청에서 오류가 발생했고 다중 레벨 컴파일 모드에서 첫 번째 빌드 중에 작동이 중단되었습니다. 현재 .NET Core 3.0에서는 기본적으로 활성화되어 있지만 원하는 경우 비활성화할 수 있습니다. 팀장, 선배, 중간, 부서장이라면 신속한 프로젝트 개발이 팀의 가치를 높이고, 이 기술을 통해 두 개발자 모두의 시간을 절약할 수 있다는 점을 이해해야 합니다. 그리고 프로젝트 자체의 시간.

.NET 레벨 업

.NET Framework/.NET Core 버전을 업그레이드하세요. 새로운 버전이 나올 때마다 성능이 향상되고 새로운 기능이 추가되는 경우가 많습니다.

그런데 정확히 어떤 이점이 있나요? 그 중 일부를 살펴보겠습니다:

• .NET Core 3.0에는 .NET Core 애플리케이션의 시작 시간을 줄이는 R2R 이미지가 도입되었습니다.
• 버전 2.2에서는 프로그래머가 프로젝트를 시작하는 데 소요되는 시간을 줄여주는 Tier Compilation이 나타났습니다.
• 새로운 .NET 표준을 지원합니다.
• 새로운 버전의 프로그래밍 언어를 지원합니다.
• 최적화, 새 버전이 나올 때마다 기본 라이브러리 Collection/Struct/Stream/String/Regex 등의 최적화가 향상됩니다. .NET Framework에서 .NET Core로 마이그레이션하는 경우 즉시 성능이 크게 향상됩니다. 예를 들어, .NET Core 3.0에 추가된 일부 최적화에 대한 링크를 첨부합니다. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

결론

코드를 작성할 때 프로젝트의 다양한 측면에 주의를 기울이고 프로그래밍 언어와 플랫폼의 기능을 사용하여 최상의 결과를 얻는 것이 좋습니다. .NET 최적화와 관련된 지식을 공유해 주시면 감사하겠습니다.

깃허브에 링크

출처 : habr.com