Veiktspēja .NET Core

Veiktspēja .NET Core

Sveiki visiem! Šis raksts ir paraugprakses apkopojums, ko es un mani kolēģi jau ilgu laiku esam izmantojuši, strādājot pie dažādiem projektiem.

Informācija par mašīnu, uz kuras tika veikti aprēķini:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60 GHz (Kaby Lake R), 1 CPU, 8 loģiskie un 4 fiziskie kodoli
.NET Core SDK=3.0.100
[Saimniekdators]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64 bitu RyuJIT
Kodols: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64 bitu RyuJIT
[Saimniekdators]: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64 bitu RyuJIT
Kodols: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64 bitu RyuJIT

Darbs=Core Runtime=Core

ToList vs ToArray un cikli

Es plānoju sagatavot šo informāciju, izlaižot .NET Core 3.0, bet viņi mani pārspēja, es nevēlos nozagt kāda cita slavu un kopēt citu informāciju, tāpēc es tikai norādīšu saite uz labu rakstu, kur ir sīki aprakstīts salīdzinājums.

Savā vārdā es tikai vēlos iepazīstināt jūs ar saviem mērījumiem un rezultātiem; es tiem pievienoju reversās cilpas rakstīšanas cilpu “C++ stila” cienītājiem.

kods:

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 un 3.0 veiktspējas ātrums ir gandrīz identisks. Lūk, ko es varēju iegūt .NET Core 3.0:

Varam secināt, ka masīvu kolekcijas iteratīvā apstrāde ir ātrāka, pateicoties tās iekšējai optimizācijai un skaidrai kolekcijas lieluma piešķiršanai. Ir arī vērts atcerēties, ka List kolekcijai ir savas priekšrocības, un jums vajadzētu izmantot pareizo kolekciju atkarībā no nepieciešamajiem aprēķiniem. Pat ja rakstāt loģiku darbam ar cilpām, neaizmirstiet, ka šī ir parasta cilpa, un tā ir pakļauta arī iespējamai cilpas optimizācijai. Pirms diezgan ilga laika habr tika publicēts raksts: https://habr.com/ru/post/124910/. Tā joprojām ir aktuāla un ieteicama lasāmviela.

Mest

Pirms gada es strādāju uzņēmumā pie mantota projekta, un šajā projektā bija normāli apstrādāt lauka validāciju, izmantojot konstrukciju “mēģini noķert un mest”. Jau tad sapratu, ka tā ir neveselīga biznesa loģika projektam, tāpēc, kad vien iespējams, centos šādu dizainu neizmantot. Bet izdomāsim, kāpēc pieeja kļūdu novēršanai ar šādu konstrukciju ir slikta. Es uzrakstīju nelielu kodu, lai salīdzinātu abas pieejas, un katrai opcijai izveidoju etalonus.

kods:

        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;
        }

Rezultātiem .NET Core 3.0 un Core 2.2 ir līdzīgs rezultāts (.NET Core 3.0):

Izmēģināšanas nozveja padara kodu grūtāk saprotamu un palielina programmas izpildes laiku. Bet, ja jums ir nepieciešama šī konstrukcija, nevajadzētu ievietot tās koda rindas, kurās nav paredzēts rīkoties ar kļūdām - tas padarīs kodu vieglāk saprotamu. Faktiski sistēmu noslogo ne tik daudz izņēmumu apstrāde, bet gan pašu kļūdu izmešana, izmantojot jauno izņēmuma konstrukciju.

Izņēmumu izmešana notiek lēnāk nekā dažas klases, kas savāks kļūdu vajadzīgajā formātā. Ja apstrādājat veidlapu vai dažus datus un skaidri zināt, kādai jābūt kļūdai, kāpēc gan to neapstrādāt?

Nevajadzētu rakstīt jaunu Exception() konstrukciju, ja šī situācija nav ārkārtēja. Izņēmuma apstrāde un mešana ir ļoti dārga!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

Savas 5 gadu pieredzes laikā, strādājot pie .NET platformas, esmu saskāries ar daudziem projektiem, kuros tika izmantota virkņu saskaņošana. Es redzēju arī šādu attēlu: bija viens Enterprise risinājums ar daudziem projektiem, no kuriem katrs veica virkņu salīdzināšanu atšķirīgi. Bet kas būtu jāizmanto un kā to unificēt? Rihtera grāmatā CLR caur C# es izlasīju informāciju, ka metode ToUpperInvariant() ir ātrāka par ToLowerInvariant().

Fragments no grāmatas:

Protams, es tam neticēju un nolēmu veikt dažus testus .NET Framework, un rezultāts mani šokēja — veiktspējas pieaugums ir vairāk nekā 15%. Pēc tam, ierodoties darbā nākamajā rītā, es parādīju šos mērījumus saviem priekšniekiem un devu viņiem piekļuvi pirmkodam. Pēc tam 2 no 14 projektiem tika mainīti, lai pielāgotos jaunajiem mērījumiem, un, ņemot vērā, ka šie divi projekti pastāvēja, lai apstrādātu milzīgas Excel tabulas, rezultāts produktam bija vairāk nekā nozīmīgs.

Piedāvāju arī mērījumus dažādām .NET Core versijām, lai katrs varētu izdarīt izvēli par optimālāko risinājumu. Un es tikai vēlos piebilst, ka uzņēmumā, kurā es strādāju, mēs izmantojam ToUpper(), lai salīdzinātu virknes.

kods:

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();
        }

Programmā .NET Core 3.0 katras no šīm metodēm pieaugums ir ~x2 un līdzsvaro implementācijas savā starpā.

Līmeņa kompilācija

Savā pēdējā rakstā es īsi aprakstīju šo funkcionalitāti, es vēlētos labot un papildināt savus vārdus. Vairāku līmeņu kompilācija paātrina jūsu risinājuma palaišanas laiku, taču jūs upurējat to, ka jūsu koda daļas fonā tiks kompilētas optimizētākā versijā, kas var radīt nelielu papildu izdevumu. Līdz ar NET Core 3.0 parādīšanos ir samazinājies izveides laiks projektiem ar iespējotu līmeņu kompilāciju, un ir novērstas ar šo tehnoloģiju saistītās kļūdas. Iepriekš šī tehnoloģija izraisīja kļūdas pirmajos ASP.NET Core pieprasījumos un sasalst pirmās versijas laikā daudzlīmeņu kompilācijas režīmā. Pašlaik tas ir iespējots pēc noklusējuma .NET Core 3.0, taču varat to atspējot, ja vēlaties. Ja esi komandas vadītāja, vecākais, vidējais vai nodaļas vadītājs, tad jāsaprot, ka strauja projektu attīstība palielina komandas vērtību un šī tehnoloģija ļaus ietaupīt laiku abiem izstrādātājiem. un paša projekta laiks.

.NET līmenis uz augšu

Jauniniet savu .NET Framework/.NET Core versiju. Bieži vien katra jaunā versija nodrošina papildu veiktspējas pieaugumu un pievieno jaunas funkcijas.

Bet kādi tieši ir ieguvumi? Apskatīsim dažus no tiem:

• .NET Core 3.0 ieviesa R2R attēlus, kas samazinās .NET Core lietojumprogrammu startēšanas laiku.
• Ar versiju 2.2 parādījās Tier Compilation, pateicoties kurai programmētāji pavadīs mazāk laika, uzsākot projektu.
• Atbalsts jauniem .NET standartiem.
• Atbalsts jaunai programmēšanas valodas versijai.
• Optimizācija, ar katru jauno versiju tiek uzlabota bāzes bibliotēku kolekcija/Struktūra/Stream/String/Regex optimizācija un daudz kas cits. Ja migrējat no .NET Framework uz .NET Core, jūs iegūsit lielu veiktspējas uzlabojumu. Kā piemēru es pievienoju saiti uz dažām optimizācijām, kas tika pievienotas .NET Core 3.0: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

Secinājums

Rakstot kodu, ir vērts pievērst uzmanību dažādiem sava projekta aspektiem un izmantot savas programmēšanas valodas un platformas iespējas, lai sasniegtu labāko rezultātu. Priecāšos, ja padalītos ar savām zināšanām par optimizāciju .NET.

Saite uz github

Avots: www.habr.com