क्या समय से पहले अनुकूलन नरक के लिए प्रिय है? या "विशेषज्ञों" से "फिर ठीक" दृष्टिकोण प्रोग्रामर को "स्कूली" में बदल देता है?

इन सवालों के स्पष्ट उत्तर नहीं हैं, हालांकि, इस लेख में मैं प्रदर्शन के लिए अपने दृष्टिकोण का वर्णन करने की कोशिश करूंगा। मैं यह सुनिश्चित करने के लिए क्या कर रहा हूं कि मेरे सिस्टम एक सभ्य गति से काम करें, लेकिन अन्य आवश्यकताओं, जैसे कि मॉड्यूलरता, रखरखाव और लचीलेपन का उल्लंघन न करें।

1. प्रोग्रामर का समय अंतिम संसाधन है

यदि आप एक बड़ा कार्यक्रम लिख रहे हैं, तो कोड के कुछ हिस्से उच्चतम सैद्धांतिक गति पर काम नहीं करेंगे। क्षमा करें। यदि आप एक बड़ा कार्यक्रम लिख रहे हैं, तो कोड का कोई भी भाग उच्चतम सैद्धांतिक गति से संभव नहीं होगा। हां, मुझे लगता है कि यह महसूस करने के लायक है कि आपके कोड की किसी भी लाइन को थोड़ी तेजी से काम करने के लिए बदला जा सकता है।

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

सभी नए फ़ंक्शंस को जोड़ने, सभी बग्स को ठीक करने और सभी कोड को ऑप्टिमाइज़ करने के लिए हमेशा पर्याप्त समय नहीं होता है। तो न्यूनतम प्रयास के लिए लक्ष्य अधिकतम प्रदर्शन होना चाहिए।

2. सादगी की शक्ति को कम मत समझो

सरल समाधान जटिल लोगों की तुलना में लागू करना आसान है। लेकिन यह केवल हिमशैल का सिरा है। सरल समाधानों की वास्तविक प्रसन्नता समय के साथ आती है। एक सरल समाधान समझना आसान है, डीबग करना आसान है, लागू करना आसान है, पोर्ट करना आसान है, प्रोफ़ाइल करना आसान है, अनुकूलन करना आसान है, समानांतर करना आसान है और प्रतिस्थापित करना आसान है। समय के साथ, ये सभी प्लसस जमा हो जाते हैं।

एक सरल समाधान का उपयोग करने से समय की बचत हो सकती है, भले ही यह एक जटिल समाधान से धीमा हो, क्योंकि सामान्य तौर पर, आपका कार्यक्रम तेजी से चलेगा क्योंकि आप अपने अन्य भागों को अनुकूलित करने के लिए सहेजे गए समय को कैसे व्यतीत करेंगे। वे हिस्से जो वास्तव में महत्वपूर्ण हैं।

मैं केवल एक वर्ष के लिए जटिल समाधानों का उपयोग करता हूं, यह वास्तव में उचित है। उदाहरण के लिए, जब एक जटिल समाधान एक साधारण (या कारक 2, या कुछ और) की तुलना में बहुत तेज होता है, और जब यह सिस्टम में होता है, जहां यह वास्तव में महत्वपूर्ण होता है (जो सीपीयू समय का एक महत्वपूर्ण प्रतिशत खपत करता है)।

बेशक, सादगी केवल एक विशिष्ट व्यक्ति को दिखाई देती है। मेरा मानना ​​है कि सरणियाँ सरल हैं। मुझे POD डेटा प्रकार सरल लगते हैं। मुझे लगता है कि बूँदें सरल हैं। मुझे नहीं लगता कि विरासत के 12 स्तरों वाली कक्षाएं सरल हैं। मुझे नहीं लगता कि 8 विभिन्न नीतियों के आधार पर कक्षाएं सरल हैं। मुझे नहीं लगता कि ज्यामितीय बीजगणित सरल है।

3. एक सिस्टम डिजाइन करने के लिए एक मौका से सब कुछ ले लो

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

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

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

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

इसलिए, "कम प्रयास के लिए अधिक उत्पादकता" की हमारी सामान्य रेखा के बाद, आप तुरंत ध्यान दे सकते हैं कि यह शुरुआत से ही प्रदर्शन समस्याओं पर विचार करने के लायक है। सिर्फ इसलिए कि इसे एक बाद के निर्धारण की तुलना में कम प्रयास की आवश्यकता होती है।

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

जब मैं सिस्टम को डिजाइन करता हूं, तो मैं एक मोटा स्केच बनाता हूं कि कितनी बार कोड के वर्गों को प्रति यूनिट समय कहा जाता है, और डिजाइन आवश्यकताओं को तैयार करता है:

• 1-10। प्रदर्शन महत्वहीन है। जो भी करो
• 100. सुनिश्चित करें कि यह O (n) है , डेटा उन्मुख है और इसे कैश किया जा सकता है
• 1000. बहु-व्यापार का उपयोग करें
• 10000. अच्छा सोचो, तुम यहाँ क्या कर रहे हो

कई सिफारिशें भी हैं जिन्हें मैं नए सिस्टम लिखते समय पालन करने की कोशिश करता हूं:

• मेमोरी के निरंतर पूरे ब्लॉक में स्थिर डेटा जोड़ें
• आसन्न मेमोरी स्थानों में डायनामिक डेटा जोड़ें
• स्मृति को बचाओ
• जटिल डेटा संरचनाओं की तुलना में ऐरे बेहतर हैं
• मेमोरी को रैखिक रूप से एक्सेस करना (कैशिंग को सरल करता है)
• सुनिश्चित करें कि कार्यों को ओ (एन) समय में निष्पादित किया जाता है
• "मैं कुछ नहीं करता" जैसे अपडेट से बचें - बेहतर सक्रिय वस्तुओं पर नज़र रखें
• यदि सिस्टम कई वस्तुओं के साथ काम करता है - डेटा के समानांतर पहुंच प्रदान करता है

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

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

4. अड़चनों को खोजने के लिए टॉप-डाउन प्रोफाइलिंग का उपयोग करें

कोई फर्क नहीं पड़ता कि आपकी मूल वास्तुकला कितनी अच्छी है, आपका कोड सबसे अप्रत्याशित स्थानों में धीमा हो जाएगा। लोग आपके सिस्टम का उपयोग craziest तरीकों से करेंगे और उन अड़चनों का पता लगाएंगे, जिनकी आपने कल्पना भी नहीं की होगी। तो वहाँ आप त्रुटि कोड में है। कुछ त्रुटियां सिस्टम को क्रैश नहीं करती हैं, लेकिन बस प्रदर्शन को नकारात्मक रूप से प्रभावित करती हैं। और ये गलतियाँ होंगी जिनके बारे में आप मूल रूप से नहीं जान सकते।

यह समझने के लिए कि आपका कार्यक्रम वास्तव में कहां समय बर्बाद कर रहा है, एक टॉप-डाउन प्रोफाइलर एक अमूल्य उपकरण है। हम स्पष्ट रूप से अपने कोड के प्रोफाइल भागों को निर्दिष्ट करते हैं और नेटवर्क पर लाइव डेटा को एक बाहरी उपकरण में स्थानांतरित करते हैं जो उन्हें विभिन्न तरीकों से कल्पना कर सकते हैं:


(पुराने) BitSquid प्रोफाइलर का स्क्रीनशॉट

टॉप-डाउन प्रोफाइलिंग आपको बताएगा कि आपके अनुकूलन प्रयासों को कहां केंद्रित किया जाए। एनिमेशन के लिए 60% समय और इंटरफ़ेस के लिए 0.5% समय का उपयोग करें? एनीमेशन में संलग्न हैं, यह काम करेगा, लेकिन इंटरफ़ेस और पैसा एक पैसा के लायक नहीं है।

ऊपर से नीचे तक की रूपरेखा आप प्रोफाइल कोड के सेगमेंट को तब तक संकीर्ण और कम कर सकते हैं जब तक कि आप प्रदर्शन की समस्या से नहीं मिलते हैं - ठीक उसी जगह जहां समय वास्तव में व्यतीत होता है।

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

5. निम्न-स्तरीय अनुकूलन लक्ष्यों को खोजने के लिए नीचे-ऊपर प्रोफाइलिंग का उपयोग करें

सामान्य तौर पर, मेरा मानना ​​है कि अच्छी तरह से परिभाषित कोड खंडों के साथ टॉप-डाउन प्रोफाइलिंग नीचे-ऊपर प्रोफाइलिंग की तुलना में अधिक उपयोगी है।

लेकिन नीचे-ऊपर प्रोफाइलिंग, हालांकि, उपयोग परिदृश्य हैं। यह हॉट स्पॉट खोजने के लिए अच्छा है - फ़ंक्शंस जो प्रोग्राम के विभिन्न हिस्सों से बुलाए जाते हैं, और जिन्हें ऊपर से नीचे तक प्रोफाइलिंग करते समय छोड़ दिया जा सकता है। ये हॉट स्पॉट निम्न स्तर के लिए अच्छे लक्ष्य हो सकते हैं, इंस्ट्रक्शन ऑप्टिमाइज़ेशन द्वारा निर्देश। या उनकी उपस्थिति इंगित करती है कि कुछ गलत किया गया है।

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

अक्सर हमारे कोड का हॉट स्पॉट lua_Vexecute () होता है। जो आश्चर्य की बात नहीं है। यह Lua VM का मुख्य कार्य है, एक बड़ा स्विच जो कि अधिकांश Lua कोड चलाता है। लेकिन यह हमें बताता है कि इस फ़ंक्शन के निम्न-स्तरीय प्लेटफ़ॉर्म-विशिष्ट अनुकूलन प्रदर्शन में एक ठोस लाभ दे सकते हैं।

6. सिंथेटिक परीक्षणों से बचें।

मैं कई सिंथेटिक परीक्षण नहीं करता हूं जैसे कि लूप में 10,000 बार कोड चलाना और रनटाइम मापना।

अगर मैं एक ऐसे हिस्से से निपटता हूं जिसमें मैं तुरंत समझ नहीं पा रहा हूं कि क्या बदलाव के बाद कोड तेज होगा, तो मैं असली गेम डेटा का बेहतर इस्तेमाल करूंगा। अन्यथा, मुझे यकीन नहीं हो सकता है कि मैं डेटा के लिए अनुकूलन नहीं कर रहा हूं जो वास्तविक जीवन में नहीं मिला है।

एक ही एनीमेशन को चलाने वाले एक इकाई के 500 उदाहरणों का परीक्षण एक ही स्थान के परीक्षण से अलग होगा, लेकिन 50 अलग-अलग इकाइयों के साथ, जिनमें से सभी के पास कई एनिमेशन हैं। डेटा एक्सेस मॉडल पूरी तरह से अलग होंगे। केवल एक मामले को शामिल करने का अनुकूलन दूसरे में मायने नहीं रखेगा।

7. अनुकूलन बागवानी है

प्रोग्रामर इंजन का अनुकूलन करते हैं। पटकथा लेखक इसमें सभी प्रकार की चीजें भरते हैं। तो यह था, है और रहेगा। और वह अच्छा है।

अनुकूलन किसी प्रकार की अलग-थलग प्रक्रिया नहीं है जो समय की एक सीमित अवधि में होती है। यह पूरे चक्र का हिस्सा है: विकास, कार्यान्वयन और विकास। ऑप्टिमाइज़ेशन प्रोग्रामर और स्क्रिप्ट राइटर के बीच एक निरंतर संवाद है कि इंजन में क्या होना चाहिए।

उत्पादकता में सुधार बगीचे की देखभाल के समान है: देखें कि सब कुछ ठीक है, खरपतवार, यह पता लगाने के लिए कि पौधे के जीवन को बेहतर कैसे बनाया जाए।

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

---

असंबद्ध अनुवाद।
प्रदर्शन के लिए मूल व्यावहारिक दृष्टिकोण

आने के साथ सभी! बहुत सारे अच्छे और तेज़ प्रोग्राम लिखें!