Performance in .NET Core

Performance in .NET Core

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

Информация за машината, на която са извършвани изчисленията:BenchmarkDotNet=v0.11.5, OS=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 vs ToArray и цикли

Планирах да подготвя тази информация с излизането на .NET Core 3.0, но ме изпревариха, не искам да крада славата на другите и да копирам чужда информация, затова просто ще посоча връзка на добра статия, в която подробно е описано сравнението.

От своя страна искам просто да представя моите измервания и резултати, добавих в тях обратните цикли за почитателите на "C++ стил" на написване на цикли.

Код:

public class Bench
    {
        private List _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  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  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

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

През петте години опит на платформата .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 времето за сборка на проектите с включена tier компилация намаля значително и бяха поправени бъгове, свързани с тази технология. По-рано тази технология водеше до грешки в първите заявки в ASP.NET Core и до забавяне при първоначалната сборка в режим на многоуровнева компилация. В момента в .NET Core 3.0 е включена по подразбиране, но можете да я деактивирате по желание. Ако заемате позиция на ръководител на екип, старши или среден програмист или сте ръководител на отдел, трябва да разбирате, че бързото разработване на проект увеличава ценността на екипа и тази технология ще ви спести време както на разработчиците, така и самото време за работа на проекта.

.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