संरचना और आसानी से: कैसे प्रदर्शन गिरावट से बचने के लिए

संरचना प्रकार और आसानी से संशोधक का उपयोग करना कभी-कभी प्रदर्शन में गिरावट का कारण बन सकता है। आज हम एक खुले स्रोत कोड विश्लेषक - ErrorProne.NET का उपयोग करके इससे बचने के बारे में बात करेंगे।



जैसा कि आप शायद मेरे पिछले प्रकाशनों " द इन-मोडिफ़ायर " और सी # में आसानी से आने वाली रचनाओं से जानते हैं (" सी में " संशोधक और आसानी से संरचनाएं ") और" रिफ लोकल्स का प्रदर्शन जाल और सी # में रिटर्न "(" स्थानीय चर का उपयोग करते समय प्रदर्शन जाल (रेफ संशोधक के साथ मान लौटाते हैं)), संरचनाओं के साथ काम करना जितना मुश्किल लग सकता है, उससे अधिक कठिन है। उत्परिवर्तन के मुद्दे को छोड़ते हुए, मैं ध्यान देता हूं कि पठनीय रूप से संशोधक के साथ संरचनाओं का व्यवहार (केवल-पढ़ने के लिए) और इसके बिना पठनीय संदर्भों में बहुत भिन्नता है।

यह माना जाता है कि प्रोग्रामिंग स्क्रिप्ट में संरचनाओं का उपयोग किया जाता है, जिन्हें उच्च प्रदर्शन की आवश्यकता होती है, और उनके साथ प्रभावी ढंग से काम करने के लिए, आपको कंपाइलर द्वारा उत्पन्न विभिन्न छिपे हुए संचालन के बारे में कुछ पता होना चाहिए ताकि यह सुनिश्चित हो सके कि संरचना अपरिवर्तित बनी हुई है।

यहां उन सावधानियों की एक संक्षिप्त सूची दी गई है जिन्हें आपको याद रखना चाहिए:

• बड़ी संरचनाओं का उपयोग करना जो मूल्य द्वारा पारित या लौटाए जाते हैं, महत्वपूर्ण कार्यक्रम निष्पादन पथ पर प्रदर्शन की समस्याएं पैदा कर सकते हैं।
• xY x की सुरक्षा प्रतिलिपि बनाने का कारण बनता है यदि:
  
  • x एक पठनीय क्षेत्र है;
  • टाइप x एक संरचना है जो बिना किसी संशोधक के है;
  • Y एक फ़ील्ड नहीं है।

एक ही नियम काम करता है यदि x संशोधक में एक पैरामीटर है, रेफ स्थानीय रूप से संशोधक के साथ एक स्थानीय चर है, या एक विधि को कॉल करने का नतीजा है जो एक readonly संदर्भ के माध्यम से एक मान लौटाता है।

यहाँ कुछ नियमों को ध्यान में रखना है। और, सबसे महत्वपूर्ण बात यह है कि इन नियमों पर भरोसा करने वाला कोड बहुत ही नाजुक होता है (यानी, कोड में किए गए बदलाव तुरंत कोड या प्रलेखन के अन्य भागों में महत्वपूर्ण बदलाव का कारण बनते हैं। लगभग।) कितने लोग नोटिस करेंगे कि public readonly int X जगह public readonly int X ; public int X { get; } public int X { get; } आमतौर पर इस्तेमाल किए गए संरचना में बिना किसी बदलाव के, प्रदर्शन को काफी प्रभावित करता है? या यह देखना कितना आसान है कि मूल्य से गुजरने के बजाय संशोधक में पैरामीटर का उपयोग करके प्रदर्शन को कम किया जा सकता है? लूप में एक पैरामीटर की संपत्ति का उपयोग करते समय यह वास्तव में संभव है, जब प्रत्येक पुनरावृत्ति पर एक सुरक्षात्मक प्रतिलिपि बनाई जाती है।

संरचनाओं के ऐसे गुण शाब्दिक रूप से विश्लेषणकर्ताओं के विकास की अपील करते हैं। और पुकार सुनी गई। ErrorProne.NET से मिलें - विश्लेषकों का एक सेट जो संरचनाओं के साथ काम करते समय इसके डिज़ाइन और प्रदर्शन को बेहतर बनाने के लिए आपको प्रोग्राम कोड बदलने की संभावना के बारे में सूचित करता है।

संदेश आउटपुट के साथ कोड विश्लेषण "एक्स संरचना को आसानी से बनाएं"

सूक्ष्म त्रुटियों और नकारात्मक प्रदर्शन के प्रभावों से बचने का सबसे अच्छा तरीका संरचनाओं का उपयोग करते समय उन्हें आसानी से संभव बनाने के लिए है। संरचना की घोषणा में आसानी से संशोधक स्पष्ट रूप से डेवलपर के इरादे को व्यक्त करता है (जोर देकर कहा गया है कि संरचना अपरिवर्तनीय है) और ऊपर वर्णित कई संदर्भों में संकलक को सुरक्षा प्रतियों से बचने में मदद करता है।



एक पठनीय संरचना की घोषणा कोड अखंडता का उल्लंघन नहीं करता है। आप बैच मोड में फिक्सर (कोड को ठीक करने की प्रक्रिया) को सुरक्षित रूप से चला सकते हैं और पूरे सॉफ्टवेयर समाधान की सभी संरचनाओं को केवल-पढ़ने के लिए घोषित कर सकते हैं।

रेफरी के लिए फ्रेंडली मॉडिफायर

अगला कदम नई सुविधाओं (संशोधक, स्थानीय रीड चर, रेफ चर आदि) का उपयोग करने की सुरक्षा का मूल्यांकन करना है। इसका मतलब यह है कि संकलक छिपी हुई सुरक्षात्मक प्रतियां नहीं बनाएगा जो प्रदर्शन को कम कर सकता है।

तीन प्रकारों पर विचार किया जा सकता है:

• Refonly अनुकूल संरचनाओं का उपयोग करें जिनके उपयोग से सुरक्षात्मक प्रतियों का निर्माण कभी नहीं होता है;
• संरचनाएँ जो आसानी से पढ़ने के लिए अनुकूल नहीं होती हैं, जिनका उपयोग पढ़ने के संदर्भ में हमेशा सुरक्षात्मक प्रतियों के निर्माण की ओर जाता है;
• तटस्थ संरचनाएं - संरचनाएं जिनके उपयोग से सुरक्षात्मक संदर्भ में उपयोग किए गए सदस्य के आधार पर वृद्धि हो सकती है।

पहली श्रेणी में आसानी से संरचना और POCO संरचनाएं शामिल हैं। कंपाइलर कभी भी सुरक्षात्मक प्रति उत्पन्न नहीं करेगा यदि संरचना आसानी से हो। POCO संरचनाओं को आसानी से पढ़ने के संदर्भ में उपयोग करना भी सुरक्षित है: खेतों तक पहुंच सुरक्षित माना जाता है, और कोई सुरक्षात्मक प्रतियां नहीं बनाई जाती हैं।

दूसरी श्रेणी आसानी से संशोधित किए बिना संरचना है जिसमें खुले क्षेत्र शामिल नहीं हैं। इस मामले में, जनता के किसी भी सदस्य तक पहुंच के संदर्भ में एक सुरक्षात्मक प्रतिलिपि बनाने का कारण होगा।

अंतिम श्रेणी सार्वजनिक या आंतरिक क्षेत्रों और सार्वजनिक या आंतरिक गुणों या विधियों के साथ संरचना है। इस मामले में, संकलक उपयोग किए गए सदस्य के आधार पर सुरक्षात्मक प्रतियां बनाता है।

यह जुदाई तुरंत चेतावनी उत्पन्न करने में मदद करता है अगर "अनफ्रेंडली" संरचना को संशोधक में पारित किया जाता है, स्थानीय चर रेफरी में संग्रहित किया जाता है, आदि।



यदि "अनफ्रेंडली" संरचना का उपयोग आसानी से फ़ील्ड के रूप में किया जाता है, तो विश्लेषक एक चेतावनी प्रदर्शित नहीं करता है, क्योंकि इस मामले में कोई विकल्प नहीं है। विशेष रूप से अनावश्यक रूप से प्रतिलिपि बनाने से बचने के लिए डिज़ाइन किए गए और रेफरी को आसानी से अनुकूलित किया जाता है। यदि इन संशोधकों के संबंध में संरचना "अनफ्रेंडली" है, तो आपके पास अन्य विकल्प हैं: किसी तर्क को मान से पास करें या किसी स्थानीय चर में प्रतिलिपि को सहेजें। इस संबंध में, पठनीय क्षेत्र अलग तरह से व्यवहार करते हैं: यदि आप प्रकार को अपरिवर्तनीय बनाना चाहते हैं, तो आपको इन क्षेत्रों का उपयोग करना चाहिए। याद रखें: कोड स्पष्ट और सुरुचिपूर्ण होना चाहिए, और केवल दूसरी तेजी से।

Bcc विश्लेषण

कंपाइलर उपयोगकर्ता से छिपी कई क्रियाएं करता है। जैसा कि पिछली पोस्ट में दिखाया गया है, यह देखना बहुत कठिन है कि एक सुरक्षात्मक प्रतिलिपि कब बनाई जा रही है।

विश्लेषक निम्नलिखित छिपी हुई प्रतियों का पता लगाता है:

1. पठनीय क्षेत्र का Bcc।
2. का Bcc।
3. रेफरी का स्थानीय पठनीय परिवर्तन।
4. Bcc रिटर्न रेफरी को आसानी से।
5. विस्तार की एक विधि के लिए मान द्वारा इस संशोधक के साथ एक पैरामीटर लेने वाली एक्सटेंशन पद्धति को कॉल करते समय Bcc।

 public struct NonReadOnlyStruct { public readonly long PublicField; public long PublicProperty { get; } public void PublicMethod() { } private static readonly NonReadOnlyStruct _ros; public static void Samples(in NonReadOnlyStruct nrs) { // Ok. Public field access causes no hidden copies var x = nrs.PublicField; // Ok. No hidden copies. x = _ros.PublicField; // Hidden copy: Property access on 'in'-parameter x = nrs.PublicProperty; // Hidden copy: Method call on readonly field _ros.PublicMethod(); ref readonly var local = ref nrs; // Hidden copy: method call on ref readonly local local.PublicMethod(); // Hidden copy: method call on ref readonly return Local().PublicMethod(); ref readonly NonReadOnlyStruct Local() => ref _ros; } } 

कृपया ध्यान दें कि विश्लेषक केवल निदान संदेश प्रदर्शित करते हैं यदि संरचना का आकार tes16 बाइट्स है।

वास्तविक परियोजनाओं में विश्लेषकों का उपयोग करना

मूल्य से बड़ी संरचनाओं का स्थानांतरण और, परिणामस्वरूप, संकलक द्वारा सुरक्षात्मक प्रतियों का निर्माण प्रदर्शन को काफी प्रभावित करता है। कम से कम यह प्रदर्शन परीक्षणों के परिणामों द्वारा दिखाया गया है। लेकिन अंत-से-अंत समय के संदर्भ में ये घटनाएं वास्तविक अनुप्रयोगों को कैसे प्रभावित करेंगी?

वास्तविक कोड का उपयोग करके एनालाइज़र का परीक्षण करने के लिए, मैंने उन्हें दो परियोजनाओं के लिए उपयोग किया: रोसलिन परियोजना और आंतरिक परियोजना जो मैं वर्तमान में Microsoft पर काम कर रहा हूं (परियोजना सख्त प्रदर्शन आवश्यकताओं के साथ एक स्वतंत्र कंप्यूटर अनुप्रयोग है); आइए इसे स्पष्टता के लिए "प्रोजेक्ट डी" कहें।

यहाँ परिणाम हैं:

1. उच्च प्रदर्शन आवश्यकताओं वाली परियोजनाओं में आमतौर पर कई संरचनाएं होती हैं, और उनमें से अधिकांश को आसानी से पढ़ा जा सकता है। उदाहरण के लिए, रोसलिन परियोजना में, विश्लेषक को लगभग 400 संरचनाएं मिलीं जो आसानी से और डी परियोजना में लगभग 300 हो सकती हैं।
2. उच्च प्रदर्शन आवश्यकताओं वाली परियोजनाओं में, नेत्रहीन प्रतियां केवल असाधारण स्थितियों में बनाई जानी चाहिए। मुझे रोजलिन परियोजना में केवल कुछ ऐसे मामले मिले, क्योंकि अधिकांश संरचनाओं में सार्वजनिक संपत्तियों के बजाय सार्वजनिक क्षेत्र हैं। यह उन स्थितियों में सुरक्षात्मक प्रतियां बनाने से बचता है जहां संरचनाएं आसानी से खेतों में जमा हो जाती हैं। प्रोजेक्ट डी में अधिक अंधी प्रतियां थीं, क्योंकि उनमें से कम से कम आधे में केवल-गुण थे (केवल पढ़ने के लिए पहुंच)।
3. संशोधक का उपयोग करते हुए भी काफी बड़े संरचनाओं के हस्तांतरण से कार्यक्रम के समय पर बहुत कम (लगभग अगोचर) प्रभाव होने की संभावना है।

मैंने प्रोजेक्ट डी में सभी 300 संरचनाओं को बदल दिया, उन्हें आसानी से बनाया, और फिर उनके उपयोग के सैकड़ों मामलों को ठीक किया, यह दर्शाता है कि वे संशोधक के साथ पारित किए गए हैं। फिर मैंने विभिन्न प्रदर्शन परिदृश्यों के लिए अंत-से-अंत पारगमन समय मापा। मतभेद सांख्यिकीय रूप से महत्वहीन थे।

क्या इसका मतलब यह है कि ऊपर वर्णित विशेषताएं बेकार हैं? बिलकुल नहीं।

उच्च प्रदर्शन आवश्यकताओं के साथ एक परियोजना पर काम करें (उदाहरण के लिए, रोसलिन या "प्रोजेक्ट डी") का अर्थ है कि बड़ी संख्या में लोग विभिन्न प्रकार के अनुकूलन पर बहुत समय बिताते हैं। वास्तव में, कुछ मामलों में, हमारे कोड में संरचनाओं को रेफ संशोधक के साथ पारित किया गया था, और कुछ प्रतियों को सुरक्षात्मक प्रतियों की पीढ़ी को बाहर करने के लिए आसानी से संशोधित किए बिना घोषित किया गया था। संशोधक के साथ संरचनाओं के हस्तांतरण के दौरान उत्पादकता वृद्धि की कमी का मतलब यह हो सकता है कि कोड अच्छी तरह से अनुकूलित था और इसके पारित होने के महत्वपूर्ण रास्तों पर संरचनाओं की अत्यधिक नकल नहीं है।

मुझे इन सुविधाओं के साथ क्या करना चाहिए?

मेरा मानना ​​है कि संरचनाओं के लिए आसानी से संशोधक का उपयोग करने के मुद्दे पर बहुत अधिक विचार की आवश्यकता नहीं है। यदि संरचना अपरिवर्तनीय है, तो पठनीय संशोधक केवल संकलक को इस तरह के डिजाइन निर्णय के लिए स्पष्ट रूप से मजबूर करता है। और ऐसी संरचनाओं के लिए सुरक्षात्मक प्रतियों की कमी सिर्फ एक बोनस है।

आज मेरी सिफारिशें इस प्रकार हैं: यदि संरचना को आसानी से पढ़ा जा सकता है, तो हर तरह से इसे इस तरह से बनाएं।

उपयोग किए गए अन्य विकल्पों की बारीकियों पर विचार किया जाता है।

पूर्व-अनुकूलन बनाम पूर्व-निराशाकरण?

हर्ब सटर ने अपनी अद्भुत पुस्तक, C ++ कोडिंग मानकों: 101 नियम, अनुशंसाओं और सर्वोत्तम प्रथाओं में "प्रारंभिक निराशावाद" की अवधारणा का परिचय दिया।

“Ceteris paribus, code जटिलता और पठनीयता, कुछ प्रभावी डिज़ाइन पैटर्न और कोडिंग मुहावरों को स्वाभाविक रूप से आपकी उंगलियों से सूखा होना चाहिए। इस तरह के कोड को इसके निराशावादी विकल्पों की तुलना में लिखना अधिक कठिन नहीं है। आप प्रारंभिक अनुकूलन नहीं करते हैं, लेकिन स्वैच्छिक निराशा से बचें। "

मेरे दृष्टिकोण से, संशोधक में एक पैरामीटर बस मामला है। यदि आप जानते हैं कि संरचना अपेक्षाकृत बड़ी (40 बाइट्स या अधिक) है, तो आप इसे हमेशा संशोधक में पास कर सकते हैं। संशोधक में उपयोग करने की लागत अपेक्षाकृत कम है, क्योंकि आपको कॉल को समायोजित करने की आवश्यकता नहीं है, और लाभ वास्तविक हो सकते हैं।

इसके विपरीत, स्थानीय चरों के लिए और पुनरावर्ती रेफ संशोधक के साथ मान वापस करने के लिए, यह मामला नहीं है। मैं कहूंगा कि पुस्तकालयों को कोड करते समय इन सुविधाओं का उपयोग किया जाना चाहिए, और उन्हें आवेदन कोड में मना करना बेहतर है (केवल अगर कोड को प्रोफाइल करने से पता नहीं चलता है कि कॉपी ऑपरेशन वास्तव में एक समस्या है)। इन विशेषताओं का उपयोग करने के लिए अतिरिक्त प्रयास की आवश्यकता होती है, और कोड रीडर के लिए इसे समझना अधिक कठिन हो जाता है।

निष्कर्ष

1. जहाँ संभव हो, संरचनाओं के लिए आसानी से संशोधक का उपयोग करें।
2. बड़ी संरचनाओं के लिए संशोधक में उपयोग करने पर विचार करें।
3. पुस्तकालयों को एनकोड करने के लिए रेफरी मॉडिफायर के साथ स्थानीय चर और वापसी मूल्यों का उपयोग करने पर विचार करें या ऐसे मामलों में जहां कोड प्रोफाइलिंग के परिणाम इंगित करते हैं कि यह उपयोगी हो सकता है।
4. कोड समस्याओं का पता लगाने और परिणाम साझा करने के लिए ErrorProne.NET का उपयोग करें।