.NET کور میں کارکردگی

.NET کور میں کارکردگی

سب کو سلام! یہ مضمون بہترین طرز عمل کا ایک مجموعہ ہے جسے میں اور میرے ساتھی ایک طویل عرصے سے مختلف پروجیکٹس پر کام کرتے ہوئے استعمال کر رہے ہیں۔

اس مشین کے بارے میں معلومات جس پر حساب کیا گیا تھا:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R)، 1 CPU، 8 منطقی اور 4 فزیکل کور
NET کور SDK=3.0.100
[میزبان]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
کور: .NET کور 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), 64bit RyuJIT
کور: .NET کور 3.0.0 (CoreCLR 4.700.19.46205، CoreFX 4.700.19.46214)، 64bit RyuJIT

جاب = کور رن ٹائم = کور

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 کور 3.0 میں حاصل کرنے کے قابل تھا:

ہم یہ نتیجہ اخذ کر سکتے ہیں کہ اری مجموعہ کی تکراری پروسیسنگ اس کی اندرونی اصلاح اور واضح مجموعہ سائز مختص کی وجہ سے تیز تر ہے۔ یہ بھی یاد رکھنے کے قابل ہے کہ فہرست مجموعہ کے اپنے فوائد ہیں اور آپ کو مطلوبہ حسابات کے لحاظ سے صحیح مجموعہ استعمال کرنا چاہیے۔ یہاں تک کہ اگر آپ لوپس کے ساتھ کام کرنے کے لیے منطق لکھتے ہیں، تو یہ نہ بھولیں کہ یہ ایک عام لوپ ہے اور یہ ممکنہ لوپ آپٹیمائزیشن سے بھی مشروط ہے۔ کافی عرصہ پہلے حبر پر ایک مضمون شائع ہوا تھا: https://habr.com/ru/post/124910/. یہ اب بھی متعلقہ ہے اور پڑھنے کی سفارش کی جاتی ہے۔

پھینک دو

ایک سال پہلے، میں نے ایک کمپنی میں میراثی پروجیکٹ پر کام کیا، اس پروجیکٹ میں ٹرائی کیچ تھرو کنسٹرکٹ کے ذریعے فیلڈ کی توثیق پر کارروائی کرنا معمول تھا۔ تب میں پہلے ہی سمجھ گیا تھا کہ یہ پروجیکٹ کے لیے غیر صحت بخش کاروباری منطق ہے، اس لیے اگر ممکن ہو تو میں نے اس طرح کے ڈیزائن کو استعمال نہ کرنے کی کوشش کی۔ لیکن آئیے یہ معلوم کریں کہ اس طرح کی تعمیر کے ساتھ غلطیوں کو سنبھالنے کا نقطہ نظر کیوں خراب ہے۔ میں نے دونوں طریقوں کا موازنہ کرنے کے لیے ایک چھوٹا کوڈ لکھا اور ہر آپشن کے لیے بینچ مارک بنائے۔

کا کوڈ:

        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):

پکڑنے کی کوشش کرنے سے کوڈ کو سمجھنا مشکل ہو جاتا ہے اور آپ کے پروگرام پر عمل درآمد کا وقت بڑھ جاتا ہے۔ لیکن اگر آپ کو اس تعمیر کی ضرورت ہے، تو آپ کو کوڈ کی وہ لائنیں داخل نہیں کرنی چاہئیں جن سے غلطیوں کو سنبھالنے کی توقع نہیں ہے - اس سے کوڈ کو سمجھنے میں آسانی ہوگی۔ درحقیقت، یہ استثنیٰ کو سنبھالنا اتنا زیادہ نہیں ہے جو سسٹم کو لوڈ کرتا ہے، بلکہ تھرو نیو ایکسپشن کنسٹرکٹ کے ذریعے خود ہی غلطیوں کو پھینکنا ہے۔

مستثنیات کو پھینکنا کچھ کلاس کے مقابلے میں سست ہے جو مطلوبہ فارمیٹ میں غلطی کو جمع کرے گا۔ اگر آپ کسی فارم یا کچھ ڈیٹا پر کارروائی کر رہے ہیں اور آپ کو واضح طور پر معلوم ہے کہ غلطی کیا ہونی چاہیے، تو اس پر کارروائی کیوں نہیں کرتے؟

اگر یہ صورتحال غیر معمولی نہیں ہے تو آپ کو تھرو نیو Exception() تعمیر نہیں لکھنا چاہئے۔ ایک استثناء کو سنبھالنا اور پھینکنا بہت مہنگا ہے!!!

ToLower، ToLowerInvariant، ToUpper، ToUpperInvariant

.NET پلیٹ فارم پر کام کرنے کے اپنے 5 سال کے تجربے میں، میں نے بہت سے ایسے پروجیکٹس دیکھے ہیں جن میں سٹرنگ میچنگ کا استعمال کیا گیا تھا۔ میں نے مندرجہ ذیل تصویر بھی دیکھی: بہت سے پروجیکٹس کے ساتھ ایک انٹرپرائز حل تھا، جن میں سے ہر ایک نے سٹرنگ کا موازنہ مختلف طریقے سے کیا۔ لیکن کیا استعمال کیا جانا چاہئے اور اسے کیسے متحد کیا جائے؟ کتاب CLR via C# by Richter میں، میں نے یہ معلومات پڑھی ہیں کہ ToUpperInvariant() طریقہ ToLowerInvariant() سے تیز ہے۔

کتاب سے اقتباس:

یقینا، میں نے اس پر یقین نہیں کیا اور پھر .NET فریم ورک پر کچھ ٹیسٹ چلانے کا فیصلہ کیا اور نتیجہ نے مجھے چونکا دیا - 15% سے زیادہ کارکردگی میں اضافہ۔ پھر، اگلی صبح کام پر پہنچنے پر، میں نے یہ پیمائشیں اپنے اعلیٰ افسران کو دکھائیں اور انہیں سورس کوڈ تک رسائی دی۔ اس کے بعد، نئی پیمائشوں کو ایڈجسٹ کرنے کے لیے 2 میں سے 14 پراجیکٹس کو تبدیل کیا گیا، اور اس بات پر غور کرتے ہوئے کہ یہ دونوں پروجیکٹ ایکسل کی بڑی میزوں پر کارروائی کرنے کے لیے موجود تھے، نتیجہ پروڈکٹ کے لیے اہم سے زیادہ تھا۔

میں آپ کو .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 کور میں پہلی درخواستوں میں خرابیوں کا باعث بنتی تھی اور ملٹی لیول کمپلیشن موڈ میں پہلی تعمیر کے دوران جم جاتی ہے۔ یہ فی الحال .NET Core 3.0 میں بطور ڈیفالٹ فعال ہے، لیکن اگر آپ چاہیں تو اسے غیر فعال کر سکتے ہیں۔ اگر آپ ٹیم لیڈ، سینئر، مڈل کے عہدے پر ہیں یا آپ کسی شعبہ کے سربراہ ہیں، تو آپ کو سمجھنا چاہیے کہ تیزی سے پروجیکٹ کی ترقی ٹیم کی قدر میں اضافہ کرتی ہے اور یہ ٹیکنالوجی آپ کو دونوں ڈویلپرز کے لیے وقت بچانے کی اجازت دے گی۔ اور اس منصوبے کا وقت۔

.NET کی سطح اوپر

اپنے .NET فریم ورک / .NET کور ورژن کو اپ گریڈ کریں۔ اکثر، ہر نیا ورژن اضافی کارکردگی کے فوائد فراہم کرتا ہے اور نئی خصوصیات شامل کرتا ہے۔

لیکن اصل میں کیا فوائد ہیں؟ آئیے ان میں سے کچھ کو دیکھتے ہیں:

• .NET Core 3.0 نے R2R امیجز متعارف کرائی ہیں جو .NET کور ایپلی کیشنز کے آغاز کے وقت کو کم کر دیں گی۔
• ورژن 2.2 کے ساتھ، ٹائر کمپلیشن ظاہر ہوا، جس کی بدولت پروگرامرز کسی پروجیکٹ کو شروع کرنے میں کم وقت صرف کریں گے۔
• نئے .NET معیارات کے لیے سپورٹ۔
• پروگرامنگ زبان کے نئے ورژن کے لیے سپورٹ۔
• آپٹیمائزیشن، ہر نئے ورژن کے ساتھ بیس لائبریریز کلیکشن/سٹرکٹ/سٹریم/اسٹرنگ/ریجیکس کی اصلاح اور بہت کچھ بہتر ہوتا ہے۔ اگر آپ .NET Framework سے .NET Core میں منتقل ہو رہے ہیں، تو آپ کو باکس سے باہر کارکردگی کا ایک بڑا فروغ ملے گا۔ مثال کے طور پر، میں کچھ اصلاحوں کا لنک منسلک کرتا ہوں جو .NET Core 3.0 میں شامل کیے گئے تھے: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

حاصل يہ ہوا

کوڈ لکھتے وقت، آپ کے پروجیکٹ کے مختلف پہلوؤں پر توجہ دینا اور بہترین نتیجہ حاصل کرنے کے لیے اپنی پروگرامنگ زبان اور پلیٹ فارم کی خصوصیات کا استعمال کرنا قابل قدر ہے۔ اگر آپ .NET میں اصلاح سے متعلق اپنے علم کا اشتراک کریں تو مجھے خوشی ہوگی۔

گیتھب سے لنک کریں۔

ماخذ: www.habr.com