Производителност в .NET Core

Производителност в .NET Core

Здравейте на всички! Тази статия е сборник от най-добри практики, които аз и моите колеги прилагаме от дълго време в различни проекти.

Информация за машината, на която са извършвани пресмятанията:BenchmarkDotNet=v0.11.5, ОС=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), 1 CPU, 8 логически и 4 физически ядра
.NET Core SDK=3.0.100
[Host]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
Core: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
[Host]: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT
Core: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT

Job=Core Runtime=Core

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:

Можем да заключим, че цикличната обработка на колекция от тип Array е по-бърза благодарение на вътрешните си оптимизации и ясното определяне на размера на колекцията. Също така не бива да забравяме, че колекцията тип List има свои предимства и трябва да използвате подходящата колекция в зависимост от необходимите изчисления. Дори когато пишете логиката на циклите, не забравяйте, че това е обикновен loop и също е подложен на възможна оптимизация. На habr отдавна излезе статия: https://habr.com/ru/post/124910/. Тя все още е актуална и се препоръчва за четене.

Throw

Преди година работех в компания върху legacy проект. В този проект обработването на валидацията на полета чрез конструкцията 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.

Изхвърлянето на изключения работи по-бавно от някакъв клас, който ще събере грешката в необходимия формат. Ако обработвате форма или някакви данни и явно знаете каква грешка трябва да бъде, защо да не я обработите?

Не пишете конструкция throw new Exception(), ако тази ситуация не е изключителна. Обработката и хвърлянето на изключение струва много!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

В рамките на 5-годишния си опит с платформата .NET съм срещал много проекти, използващи сравнение на низове. Също така видях следната картина: имаше едно Enterprise решение с много проекти, всеки от които осъществяваше сравнението на низове различно. Но какво да използваме и как да го унифицираме? В книгата CLR via C# на Рихтер открих информация, че методът 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 и балансира реализациите помежду им.

Tier Compilation

В предишната си статия описах този функционал накратко, искам да поправя и допълня своите думи. Многостепенната компилация ускорява времето за стартиране на вашето решение, но жертвате факта, че частите от вашия код ще се компилират в по-оптимизирана версия на заден план, което може да доведе до незначителни разходи. С идването на .NET Core 3.0 времето за компилиране на проекти с включена многостепенна компилация намалява и бъговете, свързани с тази технология, са поправени. Преди тази технология водеше до грешки при първите заявки в ASP.NET Core и до забавяния при първата компилация в режим на многостепенна компилация. В момента в .NET Core 3.0 тя е включена по подразбиране, но можете да я изключите по ваше желание. Ако сте на позиция team-lead, senior, middle или ръководител на отдел, трябва да разбирате, че бързата разработка на проекта увеличава ценността на екипа и тази технология ще ви спести време както на разработчиците, така и за самото време на работа по проекта.

.NET ниво нагоре

Повишете версията на вашия .NET Framework / .NET Core. Често всяка нова версия дава допълнителен ръст в производителността и добавя нови функции.

Но какви точно са предимствата? Нека разгледаме някои от тях:

• В .NET Core 3.0 се появиха R2R образи, които ще помогнат да се намали времето за стартиране на .NET Core приложения.
• С версия 2.2 се появи Tier Compilation, благодарение на която програмистите ще отделят по-малко време за стартиране на проекта.
• Поддръжка на нови стандарти .NET Standard.
• Поддръжка на новата версия на програмен език.
• Оптимизация – с всяка нова версия се подобрява оптимизацията на основните библиотеки 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.

Линк към github

Източник: habr.com