מאמר לא מוצלח על האצת השתקפות

מיד אסביר את כותרת המאמר. התוכנית המקורית הייתה לתת עצות טובות ואמינות כיצד להאיץ את השימוש בהשתקפות באמצעות דוגמה פשוטה אך מציאותית, אך במהלך הבנצ'מרקינג התברר שהשתקפות אינה איטית כמו שחשבתי, LINQ איטית יותר מאשר בסיוטים שלי. אבל בסוף התברר שגם אני עשיתי טעות במידות... פרטים על סיפור החיים הזה נמצאים בחתך ובתגובות. מכיוון שהדוגמה די נפוצה ומיושמת באופן עקרוני כפי שנעשה בדרך כלל במפעל, היא התבררה כהדגמה מעניינת למדי, כפי שנראה לי, של חיים: ההשפעה על המהירות של הנושא המרכזי של המאמר הייתה לא מורגש בגלל היגיון חיצוני: Moq, Autofac, EF Core ואחרים "bandings".

התחלתי לעבוד בהתרשמות המאמר הזה: למה השתקפות איטית

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

בהתחשב בכך שתמיד הייתה לי דעה דומה לגבי מהירות ההשתקפות, לא התכוונתי במיוחד להטיל ספק במסקנות המחבר.

לעתים קרובות אני נתקל בשימוש נאיבי בהשתקפות בארגון. הסוג נלקח. מידע על הנכס נלקח. שיטת SetValue נקראת וכולם שמחים. הערך הגיע לשדה היעד, כולם מרוצים. אנשים חכמים מאוד - קשישים וראשי צוות - כותבים את ההרחבות שלהם לאובייקט, בהתבסס על יישום נאיבי שכזה ממפים "אוניברסליים" מסוג אחד לאחר. המהות היא בדרך כלל זו: אנחנו לוקחים את כל השדות, לוקחים את כל המאפיינים, חוזרים עליהם: אם השמות של איברי הסוג תואמים, אנחנו מבצעים את SetValue. מדי פעם אנו תופסים חריגים עקב טעויות בהן לא מצאנו נכס כלשהו באחד מהסוגים, אך גם כאן יש מוצא שמשפר את הביצועים. נסה לתפוס.

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

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

השתקפות קריאה מאלצת את ה-CLR לעבור על הרכבות כדי למצוא את האחד שהם צריכים, למשוך את המטא נתונים שלהם, לנתח אותם וכו'. בנוסף, השתקפות תוך חציית רצפים מובילה להקצאה של כמות גדולה של זיכרון. אנחנו מנצלים את הזיכרון, CLR חושף את ה-GC ומתחילים אפריזים. זה אמור להיות איטי במידה ניכרת, תאמין לי. כמויות הזיכרון העצומות בשרתי ייצור מודרניים או במכונות ענן אינן מונעות עיכובים גבוהים בעיבוד. למעשה, ככל שיותר זיכרון, כך גדל הסיכוי שתשים לב איך ה-GC עובד. השתקפות היא, בתיאוריה, סמרטוט אדום נוסף עבורו.

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

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

איך זה מושג? בעיקרו של דבר, זה לא שונה מההיגיון שבו משתמשת הפלטפורמה עצמה כדי ליצור קוד JIT. כשמתודה נקראת בפעם הראשונה, היא מתבצעת קומפילציה (וכן, תהליך זה אינו מהיר); בקריאות עוקבות, השליטה מועברת למתודה שכבר הידור, ולא יהיו ירידה משמעותית בביצועים.

במקרה שלנו, אתה יכול גם להשתמש בקומפילציה של JIT ואז להשתמש בהתנהגות הקומפילציה עם אותם ביצועים כמו עמיתיו ל-AOT. ביטויים יבואו לעזרתנו במקרה זה.

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

יש בזה היגיון. השכל הישר אומר לנו שאם ניתן לקמפל ולשמור משהו במטמון, אז צריך לעשות זאת.

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

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

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

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

אנו מיישמים, יוצרים בדיקות. עובד.

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

ההיגיון הוא כדלקמן: שיטת התבנית מקבלת זוגות שנוצרו על ידי הלוגיקה הבסיסית של הנתח. שכבת ה-LINQ היא ה-parser והלוגיקה הבסיסית של הידראטור, שעושה בקשה להקשר של מסד הנתונים ומשווה מפתחות עם זוגות מה-parser (עבור פונקציות אלו יש קוד ללא LINQ לצורך השוואה). לאחר מכן, הזוגות מועברים לשיטת ההידרציה הראשית וערכי הזוגות נקבעים למאפיינים התואמים של הישות.

"מהיר" (קידומת מהיר במדדים):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

כפי שאנו יכולים לראות, נעשה שימוש באוסף סטטי עם מאפיינים מקבעים - למבדות הידור הקוראות לישות המקבעת. נוצר על ידי הקוד הבא:

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

באופן כללי זה ברור. אנו חוצים את המאפיינים, יוצרים עבורם נציגים המתקשרים לקובעים ושומרים אותם. ואז אנחנו מתקשרים כשצריך.

"איטי" (קידומת איטי במדדים):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

כאן אנו מיד עוקפים את המאפיינים ומתקשרים ישירות ל-SetValue.

לשם הבהירות וכפנייה, יישמתי שיטה נאיבית הכותבת את הערכים של צמדי המתאם שלהם ישירות לשדות הישות. קידומת - ידני.

עכשיו בואו ניקח את BenchmarkDotNet ונבחן את הביצועים. ופתאום... (ספוילר - זו לא התוצאה הנכונה, פרטים בהמשך)

מה אנחנו רואים כאן? שיטות הנושאות בניצחון את הקידומת המהירה מתבררות כאיטיות יותר כמעט בכל המעברים מאשר שיטות עם הקידומת האיטי. זה נכון גם להקצאה וגם למהירות העבודה. מצד שני, יישום יפה ואלגנטי של מיפוי בשיטות LINQ המיועדות לכך בכל מקום אפשרי, להיפך, מפחית מאוד את התפוקה. ההבדל הוא בסדר. המגמה לא משתנה עם מספרים שונים של מעברים. ההבדל היחיד הוא בקנה מידה. עם LINQ זה איטי פי 4 - 200, יש יותר אשפה בערך באותו קנה מידה.

מְעוּדכָּן

לא האמנתי למראה עיניי, אבל חשוב מכך, הקולגה שלנו לא האמין לא לעיני ולא לקוד שלי - דמיטרי טיכונוב 0x1000000. לאחר שבדקתי פעמיים את הפתרון שלי, הוא גילה בצורה מבריקה והצביע על שגיאה שפספסתי עקב מספר שינויים ביישום, ראשוני עד סופי. לאחר תיקון הבאג שנמצא בהגדרת Moq, כל התוצאות נפלו על מקומן. לפי תוצאות הבדיקה החוזרת, המגמה העיקרית לא משתנה - LINQ עדיין משפיעה על הביצועים יותר מאשר השתקפות. עם זאת, זה נחמד שהעבודה עם הידור Expression לא נעשית לשווא, והתוצאה נראית לעין הן בהקצאה והן בזמן הביצוע. ההשקה הראשונה, כאשר שדות סטטיים מאותחלים, היא באופן טבעי איטי יותר עבור השיטה ה"מהירה", אבל אז המצב משתנה.

להלן התוצאה של המבחן החוזר:

מסקנה: בעת שימוש בהשתקפות בארגון, אין צורך מיוחד לנקוט בטריקים - LINQ תאכל יותר את הפרודוקטיביות. עם זאת, בשיטות עומס גבוה הדורשות אופטימיזציה, אתה יכול לחסוך השתקפות בצורה של אתחולים ומהדרים של נציג, שיספקו אז היגיון "מהיר". כך תוכלו לשמור הן על גמישות ההשתקפות והן על מהירות היישום.

קוד ההשוואה זמין כאן. כל אחד יכול לבדוק שוב את דברי:
בדיקות HabraReflection

נ.ב.: הקוד במבחנים משתמש ב-IoC, ובמדדים הוא משתמש במבנה מפורש. העובדה היא שביישום הסופי ניתקתי את כל הגורמים שיכולים להשפיע על הביצועים ולעשות את התוצאה רועשת.

PPS: תודה למשתמש דמיטרי טיכונוב @0x1000000 על גילוי הטעות שלי בהגדרת Moq, שהשפיעה על המדידות הראשונות. אם למישהו מהקוראים יש מספיק קארמה, בבקשה תאהבו. האיש עצר, האיש קרא, האיש בדק שוב והצביע על הטעות. אני חושב שזה ראוי לכבוד ואהדה.

PPPS: תודה לקורא המוקפד שהגיע לתחתית הסגנון והעיצוב. אני בעד אחידות ונוחות. הדיפלומטיה של המצגת מותירה הרבה לרצוי, אבל לקחתי את הביקורת בחשבון. אני מבקש את הקליע.

מקור: www.habr.com