शुरुआत में या विकास के अंत में बेहतर प्रदर्शन के लिए किसी सॉफ्टवेयर का अनुकूलन करना कब बेहतर होता है?

Question

मैं एक जूनियर सॉफ्टवेयर डेवलपर हूं और मैं सोच रहा था कि बेहतर प्रदर्शन (गति) के लिए सॉफ्टवेयर का अनुकूलन करने का सबसे अच्छा समय कब होगा।

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

Comments

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

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

कोरोलरी: क्या यह या तो / या निर्णय है, या कुछ प्रदर्शन निर्णयों को जल्दी करना महत्वपूर्ण हो सकता है, जबकि दूसरों को बदनाम करना?

— रॉबर्ट हार्वे

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

— पीटर बी

कोई फर्क नहीं पड़ता कि आप इसे कैसे देखते हैं। शुरुआत में इसके साथ अनुकूलन करने के लिए कुछ भी नहीं है क्योंकि इसके साथ तुलना करने के लिए कुछ भी नहीं है। किसी चीज़ को अनुकूलित करने के लिए आपको अभी भी 2 संदर्भों की आवश्यकता है: आदर्श प्रदर्शन (आवश्यकताओं के अनुसार) और वास्तविक एक (जो आपको एक बार मिलने के बाद चलती है)।

— Laiv

Answer 1

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

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

केवल दो चीजें मुझे इस विधा से बाहर ले जाती हैं:

1. जब मैं एक पूर्ण विकसित बड़े ओ सुधार का मौका देखता हूं , तब भी जब n इतना बड़ा होता है कि कोई भी परवाह करेगा।
2. जब मेरे पास परीक्षण होते हैं जो वास्तविक प्रदर्शन की समस्याएं दिखाते हैं। दशकों के अनुभव के साथ भी मुझे अपने गणित से अधिक परीक्षणों पर भरोसा है। और मैं गणित में अच्छा हूँ।

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

Comments

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

— पीटेर बी

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

— डॉक ब्राउन

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

— डॉक ब्राउन

@PieterB: या आपके पास एक ग्राहक है जो अपने पैसे वापस पाना चाहता है क्योंकि जो उत्पाद उन्होंने खरीदा है वह इतना छोटा है कि वे इसका उपयोग नहीं कर सकते हैं।

— डॉक ब्राउन

@svidgen परीक्षणों के बिना अपठनीय कोड की गति का मूल्यांकन करना असंभव के बगल में है। गति पर ध्यान केंद्रित करने और पठनीयता की अनदेखी करने से गतिहीन गति की समस्या पैदा होती है। पठनीयता पर ध्यान केंद्रित करने से गति की समस्याएं इतनी स्पष्ट हो जाती हैं कि आपको इसके बारे में सोचना नहीं पड़ेगा। आप इसे लिखते समय देखेंगे। यहां तक ​​कि अगर आप नहीं करते हैं, तो एक बार जब आप इसे कम से कम परीक्षण करते हैं, तो आप समस्या का पता लगाने में सक्षम होंगे। यह सब देखते हुए, किसी को डिफ़ॉल्ट रूप से पठनीयता पर ध्यान केंद्रित क्यों करना चाहिए? गति पर ध्यान केंद्रित करना और पठनीयता की अनदेखी करना आपको न तो देता है।

— कैंडिड_ओरेंज

Answer 2

यदि प्रदर्शन का एक निश्चित स्तर आवश्यक है (एक गैर-कार्यात्मक आवश्यकता), तो यह शुरू से ही एक डिजाइन लक्ष्य होना चाहिए। जैसे यह प्रभावित कर सकता है कि कौन सी प्रौद्योगिकियां उपयुक्त हो सकती हैं, या आप प्रोग्राम में डेटा प्रवाह कैसे बना सकते हैं।

लेकिन सामान्य तौर पर, कोड लिखे जाने से पहले इसे अनुकूलित करना संभव नहीं है: पहले इसे काम करें, फिर इसे सही करें और, अंत में, इसे बहुत तेज़ करें ।

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

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

Answer 3

बेहतर प्रदर्शन (गति) के लिए सॉफ्टवेयर का अनुकूलन करने का सबसे अच्छा समय कब होगा।

अपने दिमाग से अवधारणा को हटाने से शुरू करें कि प्रदर्शन गति के समान है। प्रदर्शन वह है जो उपयोगकर्ता मानता है कि प्रदर्शन है ।

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

यदि आप अपना एप्लिकेशन दो बार तेजी से बनाते हैं और आप मशीन और क्रैश पर सभी मेमोरी का उपयोग करते हैं, तो उपयोगकर्ता को यह ध्यान नहीं है कि यह अब दो बार तेज है।

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

यह मानते हुए कि सॉफ्टवेयर का प्रबंधन करना बहुत बड़ा और जटिल नहीं है

यह एक भयानक धारणा है।

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

क्या इसे बेहतर बनाने के लिए शुरुआत में अधिक समय बिताना बेहतर है या क्या मुझे केवल उस सॉफ़्टवेयर को विकसित करना चाहिए जो सभी कार्यक्षमता को सही ढंग से निष्पादित करता है और फिर इसे बेहतर प्रदर्शन के लिए अनुकूलित करने के लिए आगे बढ़ें?

आप एक खाली पृष्ठ पर बैठे हैं और आप लिखते हैं कि void main() {}क्या आप अनुकूलन करना शुरू करते हैं? अनुकूलन करने के लिए कुछ भी नहीं है! सही क्रम है:

• इसे संकलित करें
• इसे सही करें
• इसे सुरुचिपूर्ण बनाएं
• जल्दी कीजिये

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

लेकिन वहां एक कदम गायब है। असली सही क्रम है:

• ग्राहकों और प्रबंधन के साथ काम करने के लिए यथार्थवादी, औसत दर्जे का प्रदर्शन मीट्रिक और लक्ष्य निर्धारित करें, यह याद रखना कि गति एकमात्र मीट्रिक नहीं है जिसकी ग्राहक देखभाल करते हैं।
• एक परीक्षण दोहन लागू करें जो आपके लक्ष्यों के खिलाफ परियोजना की वर्तमान स्थिति को ट्रैक कर सकता है
• इसे संकलित करें
• परीक्षण चलाएं। यदि आप अब अपने लक्ष्य के भीतर नहीं हैं, तो महसूस करें कि आप जल्दी खराब हो गए हैं। विज्ञान का उपयोग करें । क्या आपने एक खराब एल्गोरिथ्म शुरू किया था जिसे ठीक किया जा सकता है, या मौलिक रूप से कुछ गलत है? यदि यह मौलिक रूप से गलत है, तो शुरू करें। यदि इसे ठीक किया जा सकता है, तो एक बग दर्ज करें और बाद में वापस आ जाएं।
• इसे सही करें
• परीक्षण फिर से चलाएँ ...
• इसे सुरुचिपूर्ण बनाएं
• परीक्षण फिर से चलाएँ ...
• क्या आप अपने लक्ष्य के अनुपालन में हैं? यदि हाँ, तो समुद्र तट पर जाएँ । यदि नहीं, तो इसे पर्याप्त उपवास करें ।

Comments

"प्रदर्शन वह है जो उपयोगकर्ता मानता है कि प्रदर्शन है।" - वास्तव में, कभी-कभी उपयोगकर्ता अनुभव वास्तव में बेहतर होता है जब हम चीजों को समय लेने की उम्मीद करते हैं: webdesignerdepot.com/2017/09/when-slower-ux-is-better-ux

— svidgen

शायद "वैज्ञानिक हो" के बजाय "विज्ञान का उपयोग करें" :)

— ब्लू

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

— जियोर्जियो

@ जियोर्जियो: यह मुझे तारीख करता है, लेकिन मुझे याद है कि जब मुझे पहली बार एक हार्ड ड्राइव मिली थी, और मैं एक गेम या एक दस्तावेज को बचाऊंगा और सोचूंगा कि कुछ गलत हो गया था क्योंकि फ्लॉपी डिस्क को बचाने के मुकाबले ऑपरेशन में कोई उल्लेखनीय समय नहीं लगा। और निश्चित रूप से अब खेल की स्थिति और दस्तावेज इतने बड़े हैं कि हम समय बचाने के लिए वापस आ रहे हैं।

— एरिक लिपर्ट

Answer 4

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

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

मैं एक उदाहरण दूंगा जिसे मैंने कई बार देखा है; ORM लाइब्रेरी दी गई, हमारे पास एक उपयोगकर्ता इकाई है जिसमें एक या अधिक ऑर्डर हो सकते हैं। चलो एक उपयोगकर्ता के लिए सभी आदेशों को लूप करते हैं, और पता करते हैं कि उपयोगकर्ता ने हमारे स्टोर में कितना खर्च किया है - एक भोली दृष्टिकोण:

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

मैंने देखा है कि डेवलपर्स इसी तरह की बातें लिखते हैं, बिना किसी निहितार्थ के; पहले हमें उपयोगकर्ता मिलता है, जो उम्मीद करता है कि उपयोगकर्ता की मेज पर सिर्फ एक एसक्यूएल क्वेरी होगी (लेकिन इसमें बहुत कुछ शामिल हो सकता है), फिर हम ऑर्डर के माध्यम से लूप करते हैं, जिसमें ऑर्डर पर सभी ऑर्डर लाइनों के लिए सभी प्रासंगिक डेटा शामिल हो सकते हैं। , उत्पाद जानकारी, आदि - यह सब सिर्फ प्रत्येक आदेश के लिए एक पूर्णांक प्राप्त करने के लिए!

यहां SQL प्रश्नों की मात्रा आपको आश्चर्यचकित कर सकती है। बेशक, यह इस बात पर निर्भर करता है कि आपकी संस्थाएँ किस प्रकार संरचित हैं।

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

Answer 5

कुल सिस्टम प्रदर्शन सिस्टम घटकों की समग्रता के जटिल इंटरैक्शन का एक उत्पाद है। यह एक नॉनलाइनर सिस्टम है। इसलिए प्रदर्शन केवल घटकों के व्यक्तिगत प्रदर्शन से नहीं, बल्कि उनके बीच की अड़चनों से होगा।

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

मामलों को और अधिक कठिन बनाने के लिए, जब आप किसी उत्पादन-जैसे परिवेश पर स्विच करते हैं, तो आपकी प्रदर्शन प्रोफ़ाइल में भारी बदलाव आ सकता है, जो अक्सर जल्दी उपलब्ध नहीं होता है।

तो तुम क्या करते हो? खैर, कुछ बातें।

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

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

3. जल्दी न अपनाएं। आप कभी नहीं जानते कि क्या महत्वपूर्ण होने जा रहा है और क्या मायने नहीं रखने वाला है; यदि आपका प्रोग्राम लगातार I / O पर प्रतीक्षा कर रहा है, तो एक सुपरफास्ट स्ट्रिंग पार्सिंग एल्गोरिदम मदद नहीं कर सकता है।

4. विशेष रूप से वेब अनुप्रयोगों में, आप प्रदर्शन पर नहीं, बल्कि स्केलबिलिटी पर ध्यान केंद्रित कर सकते हैं। यदि आवेदन समाप्त हो सकता है, तो प्रदर्शन लगभग कोई फर्क नहीं पड़ता है, क्योंकि आप अपने खेत में नोड्स जोड़कर रख सकते हैं जब तक कि यह पर्याप्त तेज न हो।

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

इनमें से अधिकांश गतिविधियाँ परियोजना की शुरुआत या समाप्ति के लिए नहीं हैं, लेकिन निरंतर रूप से भाग लेना चाहिए ।

Answer 6

मैं एक जूनियर सॉफ्टवेयर डेवलपर हूं और मैं सोच रहा था कि बेहतर प्रदर्शन (गति) के लिए सॉफ्टवेयर का अनुकूलन करने का सबसे अच्छा समय कब होगा।

समझें कि 2 बहुत अलग चरम सीमाएं हैं।

पहली चरम चीजें हैं जो डिज़ाइन के एक बड़े हिस्से को प्रभावित करती हैं, जैसे कि कार्य को कितनी प्रक्रियाओं और / या थ्रेड्स में विभाजित करना है और कैसे टुकड़े संवाद करते हैं (टीसीपी / आईपी सॉकेट? डायरेक्ट फ़ंक्शन कॉल?), क्या एक उन्नत जेआईटी को लागू करना है? या एक "एक समय में एक opcode" दुभाषिया, या SIMD के लिए उत्तरदायी होने के लिए डेटा संरचनाओं की योजना बनाने के लिए, या ... इन चीजों के कार्यान्वयन पर एक मजबूत प्रभाव पड़ता है और रेट्रो-फिट होने के बाद अत्यधिक मुश्किल / महंगा हो जाता है।

अन्य चरम माइक्रो-ऑप्टिमाइज़ेशन है - सभी जगह छोटे छोटे मोड़। इन चीजों का कार्यान्वयन पर लगभग कोई प्रभाव नहीं पड़ता है (और अक्सर किसी भी तरह से कंपाइलर द्वारा सबसे अच्छा किया जाता है), और जब भी आप ऐसा महसूस करते हैं, तो ये अनुकूलन करने के लिए तुच्छ होते हैं।

इन छोरों के बीच में एक विशाल ग्रे क्षेत्र है।

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

दुर्भाग्य से हम एक ऐसी दुनिया में रहते हैं जहाँ अभी तक बहुत सारे लोग सोचते हैं कि अनुकूलन में केवल (बहुत ही अप्रासंगिक) चीज़ें शामिल हैं "चरम" चरम पर।

Answer 7

कोड लिखना सबसे आसान है जो न तो पोरफॉर्मेंट है और न ही मेंटेनेंस योग्य है। झरझरा कोड लिखना कठिन है। यह अभी तक बनाए रखने योग्य कोड लिखने के लिए कठिन है। और यह कोड लिखने में सबसे कठिन है जो कि अनुरक्षणीय और प्रदर्शनकारी दोनों है।

लेकिन, प्रदर्शन कोड को बनाए रखने की तुलना में बनाए रखने योग्य कोड प्रदर्शन करना आसान है।

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

हालांकि, आधुनिक हार्डवेयर की स्थिति को देखते हुए, अधिकांश प्रणालियों में, शुरुआत से अनुकूलन पर विशेष ध्यान देने की आवश्यकता नहीं होती है, बल्कि प्रदर्शन विनाश से बचने के लिए आमतौर पर पर्याप्त है। मेरे कहने का मतलब यह है कि स्पष्ट रूप से मूर्खतापूर्ण कार्य करने से बचें, जैसे कि तालिका के सभी रिकॉर्डों को वापस लाने के बजाय केवल क्वेरी करने के लिए select count(*) from table। बस गलतियाँ करने से बचें और आपके द्वारा उपयोग किए जा रहे उपकरणों को समझने का प्रयास करें।

अगला, पहले अपने कोड को बनाए रखने पर ध्यान दें। इसके द्वारा, मेरा मतलब है:

1. चिंताओं को जितनी सख्ती से अलग कर सकते हैं (उदाहरण के लिए, व्यावसायिक तर्क के साथ डेटा का उपयोग न करें)
2. जहाँ संभव हो ठोस के बजाय संदर्भ सार प्रकार
3. अपने कोड को परीक्षण योग्य बनाएं

बनाए रखने के कोड बनाए रखने के लिए आसान है जब आँकड़े दिखाता है कि यह आवश्यक है।

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

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

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

Answer 8

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

अजीबोगरीब मामले

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

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

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

जितना हो सके उतनी देरी से

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

डिजाइन जो बाद में अनुकूलन करने के लिए श्वास कक्ष प्रदान करता है

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

विशेष रूप से मेरी पसंदीदा साइट और एप्लेट में प्रदर्शन खामियों (किसी भी गैर-तुच्छ ब्रश का आकार क्रॉल करने के लिए धीमा होगा) से भरा था, लेकिन एक बहुत अच्छा समुदाय था। प्रदर्शन के मुद्दों के आसपास काम करने के लिए मैंने नन्हा 1 या 2-पिक्सेल ब्रश का इस्तेमाल किया और बस अपने काम को इस तरह अंजाम दिया:

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

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

मुझे लगता है कि यह "सामान्य ज्ञान" का उल्लंघन है, लेकिन जाहिर है कि यह डेवलपर के लिए ऐसा सामान्य ज्ञान नहीं था। लेकिन यह ऐसे दानेदार स्तर पर अमूर्त चीजों की तरह नहीं है, जहां सबसे बुनियादी उपयोग के मामले भी लाखों लोगों द्वारा तात्कालिक होने जा रहे हैं, जैसे कि पिक्सल, या कण, या एक छोटे से सेना सिमुलेशन में छोटी इकाइयां। एहसान IImageया (आप सभी छवि / पिक्सेल प्रारूपों आपको लगता है कि bulkier समग्र स्तर पर की जरूरत है संभाल कर सकते हैं) IParticleSystemके लिए IPixelया IParticle, और फिर आप सबसे बुनियादी और त्वरित करने के लिए लिखने और सरल समझने-में-इस तरह के इंटरफेस के पीछे कार्यान्वयन और में डाल सकते हैं पूरे कमरे के डिजाइन पर पुनर्विचार किए बिना, आपको कभी भी सांस लेने की आवश्यकता होगी।

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

बेशक, मैं जरूरी नहीं कि इनपुट पर द्विघात जटिलता एल्गोरिदम का उपयोग शुरू करने का सुझाव दे रहा हूं जो आसानी से आम उपयोगकर्ता-अंत मामलों में एक गैर-तुच्छ आकार तक पहुंच जाता है। वैसे भी कौन करता है? लेकिन मैं यह भी नहीं सोचता कि अगर कार्यान्वयन बाद में आसान हो जाए तो यह बहुत बड़ी बात है। यदि आप किसी भी डिजाइन पर पुनर्विचार नहीं करना चाहते हैं, तो यह अभी भी गंभीर गलती नहीं है।

Answer 9

यह इस बात पर निर्भर करता है कि आपके आवेदन के लिए उस प्रदर्शन का क्या मतलब है। और यह कि क्या आपके आवेदन को कार्यात्मक रूप से पूरा होने से पहले प्रदर्शन को अनुकूलित करना संभव है।

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

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

Answer 10

मेरा सुझाव है कि प्रदर्शन गति से अधिक है। इसमें स्केल (समवर्ती उपयोगकर्ताओं के सैकड़ों से हजार) शामिल हैं। यह सुनिश्चित करने के लिए कि आप अनुप्रयोग को तब लोड नहीं करना चाहते जब इसे उत्पादन लोड मिलता है। प्रदर्शन में यह शामिल है कि एप्लिकेशन कितना संसाधन (उदाहरण के लिए मेमोरी) का उपभोग करता है।

प्रदर्शन भी उपयोग में आसानी है। कुछ उपयोगकर्ताओं को 1 सेकंड में 2 कुंजी स्ट्रोक कार्य करने की तुलना में 10 सेकंड में एक कार्य करना होगा। सामान की तरह है कि अपने डिजाइन का नेतृत्व पूछना। मैं इस तरह के उपयोगकर्ताओं को जल्दी सामान लेना पसंद नहीं करता। एक वैक्यूम में वे X कह सकते हैं लेकिन एक बार जब वे एक कार्यात्मक पूर्व-रिलीज़ के साथ काम कर रहे हैं तो वे कह सकते हैं कि Y।

एक डेटाबेस कनेक्शन जैसे संसाधन को रखने के लिए सबसे अच्छी व्यक्तिगत गति है। लेकिन पैमाने के लिए आपको कनेक्शन को जितनी जल्दी हो सके उतनी देर से प्राप्त करना चाहिए और जितनी जल्दी हो सके इसे जारी करना चाहिए। 3 चीजों को प्राप्त करने के लिए डेटाबेस की एक यात्रा डेटाबेस की 3 अलग-अलग यात्राओं से तेज है।

क्या आप उन सूचनाओं के लिए एक यात्रा कर रहे हैं जो सत्र के दौरान नहीं बदलती हैं। यदि ऐसा है तो इसे सत्र प्रारंभ में पकड़ लें और यह स्मृति है।

संग्रह प्रकार उठाते समय कार्यात्मक, गति और आकार पर विचार करें।

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

क्या आप तीन बार लूप कर रहे हैं जब आप एक बार लूप कर सकते हैं और तीन चीजें कर सकते हैं।

क्या कोई स्पॉट है जहां आपको कॉल बैक के साथ किसी अन्य थ्रेड पर प्रक्रिया करने की आवश्यकता हो सकती है। यदि ऐसा है तो कोड को उस संभावित आवश्यकता को ध्यान में रखें यदि यह तत्काल डिजाइन की जरूरतों के साथ हस्तक्षेप नहीं करता है।

बहुत सारे प्रदर्शन भी क्लीन कोड होते हैं।

समय से पहले अनुकूलन होता है और सामने सामान्य ज्ञान सामान होता है जो वास्तव में अधिक समय नहीं लेता है।

डेटाबेस में मैं समय से पहले अनुकूलन देख रहा हूँ। गति की समस्या होने से पहले विल को गति के लिए सामान्य करना होगा। मुझे जो तर्क मिलता है अगर हम बाद में तालिका बदलते हैं तो हमें सब कुछ बदलना होगा। अक्सर आप इस तरह से डेटा को प्रस्तुत करने वाला एक दृश्य बना सकते हैं और इसे बाद में डी-सामान्यीकृत तालिका के लिए स्वैप करने की आवश्यकता हो सकती है।