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

Производителност в .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
[Хост]: .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), 64bit 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), 64bit RyuJIT

Job=Core Runtime=Core

ToList срещу ToArray и Cycles

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

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

Хвърлям

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

Връзка към github

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