.NET कोर मा प्रदर्शन

.NET कोर मा प्रदर्शन

सबैलाई नमस्कार! यो लेख मेरा सहकर्मीहरू र मैले लामो समयदेखि विभिन्न परियोजनाहरूमा काम गर्दा प्रयोग गर्दै आएका उत्तम अभ्यासहरूको संग्रह हो।

गणना गरिएको मेसिनको बारेमा जानकारी:बेन्चमार्कडटनेट=v0.11.5, ओएस=विन्डोज १०.०.१८३६२
इन्टेल कोर i5-8250U CPU १.६०GHz (Kaby Lake R), १ CPU, ८ लजिकल र ४ भौतिक कोर
.NET कोर SDK=३.०.१००
[होस्ट]: .NET कोर २.२.७ (कोरसीएलआर ४.६.२८००८.०२, कोरएफएक्स ४.६.२८००८.०३), ६४ बिट रयुजिट
कोर: .NET कोर २.२.७ (कोरसीएलआर ४.६.२८००८.०२, कोरएफएक्स ४.६.२८००८.०३), ६४ बिट रयुजेआईटी
[होस्ट]: .NET कोर २.२.७ (कोरसीएलआर ४.६.२८००८.०२, कोरएफएक्स ४.६.२८००८.०३), ६४ बिट रयुजिट
कोर: .NET कोर २.२.७ (कोरसीएलआर ४.६.२८००८.०२, कोरएफएक्स ४.६.२८००८.०३), ६४ बिट रयुजेआईटी

काम = कोर रनटाइम = कोर

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/यो अझै पनि सान्दर्भिक छ र पढ्न सिफारिस गरिएको छ।

Thrower

एक वर्ष पहिले मैले एउटा कम्पनीमा एउटा लिगेसी प्रोजेक्टमा काम गरेको थिएँ, त्यो प्रोजेक्टमा ट्राइ-क्याच-थ्रो कन्स्ट्रक्सन मार्फत फिल्ड भ्यालिडेसन ह्यान्डल गर्नु सामान्य थियो। मैले त्यतिबेला नै बुझेको थिएँ कि यो प्रोजेक्टको लागि अस्वस्थ व्यावसायिक तर्क हो, त्यसैले मैले सम्भव भएसम्म यस्तो कन्स्ट्रक्सन प्रयोग नगर्ने प्रयास गरें। तर यस्तो कन्स्ट्रक्सनसँग त्रुटिहरू ह्यान्डल गर्ने दृष्टिकोण किन खराब छ भनेर पत्ता लगाऔं। मैले दुई दृष्टिकोणहरूको तुलना गर्न एउटा सानो कोड लेखें र प्रत्येक विकल्पको लागि "बेन्चमार्क" लिएँ।

कोड:

        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() construct लेख्नु हुँदैन। अपवादलाई ह्यान्डल गर्नु र फ्याँक्नु धेरै महँगो छ!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

.NET प्लेटफर्ममा काम गरेको मेरो ५ वर्षको अनुभवमा, मैले धेरै परियोजनाहरू भेटेको छु जसले स्ट्रिङ तुलना प्रयोग गर्थे। मैले निम्न तस्वीर पनि देखेको छु: धेरै परियोजनाहरू भएको एउटा इन्टरप्राइज समाधान थियो, जसमध्ये प्रत्येकले स्ट्रिङ तुलना फरक तरिकाले प्रदर्शन गर्थ्यो। तर के प्रयोग गर्नुपर्छ र यसलाई कसरी एकीकृत गर्ने? रिक्टरको पुस्तक CLR via C# मा, मैले ToUpperInvariant() विधि ToLowerInvariant() भन्दा छिटो काम गर्छ भन्ने जानकारी पढेको छु।

पुस्तकबाट अंश:

अवश्य पनि, मैले यो विश्वास गरिनँ र त्यतिबेला .NET फ्रेमवर्कमा केही परीक्षणहरू गर्ने निर्णय गरें र नतिजाले मलाई स्तब्ध बनायो - उत्पादकतामा १५% भन्दा बढी वृद्धि। त्यसपछि, भोलिपल्ट बिहान काममा आउँदा, मैले मेरा हाकिमहरूलाई यी मापनहरू देखाएँ र उनीहरूलाई स्रोत कोडमा पहुँच दिएँ। त्यसपछि, १४ मध्ये २ परियोजनाहरू नयाँ मापनहरू फिट गर्न परिवर्तन गरियो, र यी दुई परियोजनाहरू विशाल एक्सेल तालिकाहरू प्रशोधन गर्न अवस्थित भएकोले, परिणाम उत्पादनको लागि महत्त्वपूर्ण भन्दा बढी थियो।

म तपाईंलाई .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 फ्रेमवर्क / .NET कोर संस्करण अपग्रेड गर्नुहोस्। प्रायः, प्रत्येक नयाँ संस्करणले अतिरिक्त कार्यसम्पादन लाभ प्रदान गर्दछ र नयाँ सुविधाहरू थप्छ।

तर यसका खास फाइदाहरू के के हुन्? आउनुहोस्, तीमध्ये केही हेरौं:

• .NET Core 3.0 ले R2R छविहरू प्रस्तुत गर्दछ, जसले .NET Core अनुप्रयोगहरूको स्टार्टअप समय घटाउन मद्दत गर्नेछ।
• संस्करण २.२ देखि, टियर कम्पाइलेसन देखा परेको छ, जसको कारण प्रोग्रामरहरूले परियोजना सुरु गर्न कम समय खर्च गर्नेछन्।
• नयाँ .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 मा अप्टिमाइजेसनसँग सम्बन्धित आफ्नो ज्ञान साझा गर्नुभयो भने म खुसी हुनेछु।

गिथबको लिङ्क

स्रोत: www.habr.com