ביצועים ב-.NET Core

ביצועים ב-.NET Core

שלום לכולם! מאמר זה הוא אוסף של שיטות עבודה מומלצות שעמיתיי ואני השתמשנו במשך זמן רב כאשר עובדים על פרויקטים שונים.

מידע על המכונה שבה בוצעו החישובים:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), מעבד אחד, 1 ליבות לוגיות ו-8 פיזיות
.NET Core SDK=3.0.100
[מארח]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit 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), 64bit RyuJIT
ליבה: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT

Job=Core Runtime=Core

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:

אנו יכולים להסיק שעיבוד איטרטיבי של אוסף מערך מהיר יותר בשל האופטימיזציות הפנימיות שלו והקצאת גודל האוסף המפורשת שלו. כדאי גם לזכור שלאוסף 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 מקשה על הבנת הקוד ומגדיל את זמן הביצוע של התוכנית שלך. אבל אם אתה צריך את הבנייה הזו, אתה לא צריך להכניס את שורות הקוד שלא צפויות לטפל בשגיאות - זה יקל על הבנת הקוד. למעשה, לא כל כך הטיפול בחריגים טוען את המערכת, אלא השלכת השגיאות עצמן דרך מבנה ה-exception new throw.

זריקת חריגים איטית יותר מאשר מחלקה כלשהי שתאסוף את השגיאה בפורמט הנדרש. אם אתה מעבד טופס או נתונים מסוימים ואתה יודע בבירור מה צריכה להיות השגיאה, למה לא לעבד אותה?

אין לכתוב מבנה () throw new Exception אם מצב זה אינו חריג. טיפול וזריקת חריג יקר מאוד!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

במהלך 5 שנות הניסיון שלי בעבודה על פלטפורמת NET, נתקלתי בפרויקטים רבים שהשתמשו בהתאמת מחרוזות. ראיתי גם את התמונה הבאה: היה פתרון Enterprise אחד עם הרבה פרויקטים, שכל אחד מהם ביצע השוואות מחרוזות בצורה שונה. אבל במה יש להשתמש וכיצד לאחד אותו? בספר CLR via C# מאת Richter, קראתי מידע ששיטת ToUpperInvariant() מהירה יותר מ-ToLowerInvariant().

קטע מהספר:

כמובן, לא האמנתי והחלטתי להריץ אז כמה בדיקות ב-.NET Framework והתוצאה זעזעה אותי - עלייה של יותר מ-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 Core והקפאה במהלך הבנייה הראשונה במצב קומפילציה מרובת רמות. זה מופעל כרגע כברירת מחדל ב-.NET Core 3.0, אבל אתה יכול להשבית אותו אם תרצה. אם אתה בעמדה של ראש צוות, בכיר, אמצעי, או שאתה ראש מחלקה, אז אתה חייב להבין שפיתוח מהיר של פרויקטים מעלה את הערך של הצוות והטכנולוגיה הזו תאפשר לך לחסוך זמן לשני המפתחים וזמן הפרויקט עצמו.

רמת NET עולה

שדרג את גרסת ה-.NET Framework / .NET Core שלך. לעתים קרובות, כל גרסה חדשה מספקת שיפורי ביצועים נוספים ומוסיפה תכונות חדשות.

אבל מה בדיוק היתרונות? בואו נסתכל על כמה מהם:

• NET Core 3.0 הציג תמונות R2R שיפחיתו את זמן האתחול של יישומי .NET Core.
• עם גרסה 2.2 הופיע קומפילציה שכבתית, שבזכותה מתכנתים ישקיעו פחות זמן בהשקת פרויקט.
• תמיכה בתקני 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