क्या समयपूर्व अनुकूलन वास्तव में सभी बुराई की जड़ है?

215

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

design optimization architecture

— क्रेग डे
स्रोत

22

मुझे लगता है कि आपको समय से पहले अनुकूलन और अनावश्यक अनुकूलन के बीच अंतर करने की आवश्यकता है। मेरे लिए समय से पहले 'जीवन चक्र में बहुत जल्दी' सुझाव गैर जरूरी है 'महत्वपूर्ण मूल्य नहीं जोड़ता है'। IMO, देर से अनुकूलन के लिए आवश्यकता घटिया डिजाइन का मतलब है।

109

हां, लेकिन बुराई एक बहुपद है और कई जड़ें हैं, उनमें से कुछ जटिल हैं।

— dan_waterworth

7

आपको विचार करना चाहिए, कि नूथ ने यह 1974 में लिखा था। सत्तर के दशक में यह इतना धीमा कार्यक्रम लिखना आसान नहीं था जितना आजकल है। उन्होंने पास्कल को ध्यान में रखते हुए लिखा है कि जावा या पीएचपी के साथ नहीं।

— छत

4

नहीं, सभी बुराई की जड़ लालच है।

— तुलसी कोर्डोवा

12

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

— एलेक्स

322

पूर्ण उद्धरण को ध्यान में रखना महत्वपूर्ण है:

हमें छोटी क्षमताओं के बारे में भूलना चाहिए, समय के 97% के बारे में कहना चाहिए: समय से पहले अनुकूलन सभी बुराई की जड़ है। फिर भी हमें उस गंभीर 3% में अपने अवसरों को पारित नहीं करना चाहिए।

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

"समय से पहले अनुकूलन" के साथ सबसे बड़ी समस्या यह है कि यह अप्रत्याशित बगों को पेश कर सकता है और एक विशाल समय नुक़सान हो सकता है।

— स्कॉट डोरमैन
स्रोत

7

डोनाल्ड नथ से होने के नाते, अगर वह इसे वापस करने के लिए कुछ सबूत था, तो मुझे आश्चर्य नहीं होगा। BTW, Src: स्ट्रक्चर्ड प्रोग्रामिंग टू स्टेट्स टू गो, एसीएम जर्नल कम्प्यूटिंग सर्वे, वॉल्यूम 6, नंबर 4, दिसंबर 1974। पृष्ठ.268। citeseerx.ist.psu.edu/viewdoc/…

— mctylr

28

... एक अच्छे प्रोग्रामर को इस तरह के तर्क से शालीनता में नहीं चुना जाएगा, वह महत्वपूर्ण कोड को ध्यान से देखने के लिए बुद्धिमान होगा; लेकिन उसके बाद ही उस कोड की पहचान की गई (बाकी पूरा उद्धरण)

— mctylr

21

मेरे पास 20k प्रतिनिधि उपयोगकर्ता था जो आज मुझे बताता है कि HashSetएक Listसमय से पहले अनुकूलन के बजाय का उपयोग कर रहा था। विचाराधीन उपयोग मामला एक वैधानिक रूप से आरंभिक संग्रह था, एकमात्र उद्देश्य लुक-अप टेबल के रूप में सेवा करना था। मुझे नहीं लगता कि यह कहना गलत है कि काम बनाम समय से पहले अनुकूलन के लिए सही उपकरण का चयन करने में कोई अंतर है। मुझे लगता है कि आपकी पोस्ट इस दर्शन की पुष्टि करती है:

There are obvious optimizations...anything that isn't trivially clear optimization should be avoided until it can be measured.

एक हैशसेट का अनुकूलन पूरी तरह से मापा और प्रलेखित किया गया है।

— क्रश करें

9

@ क्रश: हाँ: Setसे भी अधिक शब्दार्थिक रूप से सही और सूचनात्मक है List, इसलिए इसके लिए अनुकूलन पहलू से अधिक है।

— एरिक एलिक

7

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

— एरिक अल्लिक

111

समयपूर्व माइक्रो ऑप्टिमाइज़ेशन सभी बुराई की जड़ हैं, क्योंकि माइक्रो ऑप्टिमाइज़ेशन संदर्भ को छोड़ देते हैं। वे लगभग कभी भी उस तरह का व्यवहार नहीं करते हैं जैसी उनसे उम्मीद की जाती है।

महत्व के क्रम में कुछ अच्छे शुरुआती अनुकूलन क्या हैं:

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

कुछ मध्य विकास चक्र अनुकूलन:

डेटा संरचनाएं, नए डेटा संरचनाओं को प्रस्तुत करती हैं जिनके लिए आवश्यक होने पर बेहतर प्रदर्शन या कम ओवरहेड होता है
एल्गोरिदम (अब quicksort3 और heapsort ;-) के बीच निर्णय लेना शुरू करने का अच्छा समय है;)

कुछ अंत विकास चक्र अनुकूलन

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

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

यदि प्रदर्शन चिंता का है (और हमेशा होना चाहिए) हमेशा बड़ा सोचें । प्रदर्शन एक बड़ी तस्वीर है और चीजों के बारे में नहीं जैसे कि: मुझे इंट या लंबे का उपयोग करना चाहिए ? बॉटम अप के बजाय प्रदर्शन के साथ काम करते समय टॉप डाउन के लिए जाएं ।

— पॉप कैटलिन
स्रोत

"अनुकूलन: आपका सबसे बड़ा दुश्मन", जोसेफ एम। न्यूकमर द्वारा: flounder.com/optimization.htm

— रॉन रूबल

53

पहली माप के बिना अनुकूलन लगभग हमेशा समय से पहले होता है।

मेरा मानना है कि इस मामले में यह सच है, और सामान्य मामले में भी सच है।

— जेफ एटवुड
स्रोत

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

— जेम्स एंडरसन

जब तक यह प्रलेखित न हो।

— नवफाल

हाँ। पूर्णतया सहमत। इसे पहले नापना होगा। ऐसा कोई तरीका नहीं है जिससे आप यह जान सकें कि अड़चनें तब तक हैं जब तक कि आप कुछ अंत का परीक्षण नहीं करते हैं और प्रत्येक चरण को मापते हैं।

— ओलिवर वाटकिंस

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

— बेंगी

42

यदि यह कारण है तो अनुकूलन "बुराई" है:

कम स्पष्ट कोड
काफी अधिक कोड
कम सुरक्षित कोड
व्यर्थ प्रोग्रामर समय

आपके मामले में, ऐसा लगता है कि थोड़ा प्रोग्रामर समय पहले से ही खर्च किया गया था, कोड बहुत जटिल नहीं था (आपकी टिप्पणी से एक अनुमान जो टीम के सभी लोग समझ सकेंगे), और कोड थोड़ा और अधिक भविष्य का प्रमाण है (होने के नाते) धागा सुरक्षित अब, अगर मैं आपका वर्णन समझ गया)। लगता है केवल थोड़ी बुराई है। :)

— जॉन मुल्डर
स्रोत

4

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

1

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

— jhocking

8

कोड थ्रेड को सुरक्षित बनाना अनुकूलन नहीं है।

— मत्तनाज

38

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

यहां एक बड़ा उद्धरण (पीडीएफ के पेज 8, मूल में पृष्ठ 268 से):

उदाहरण 2 से उदाहरण 2 ए तक की गति में सुधार केवल लगभग 12% है, और बहुत से लोग उस तुच्छ का उच्चारण करेंगे। आज के सॉफ्टवेयर इंजीनियरों द्वारा साझा किए गए पारंपरिक ज्ञान छोटे में दक्षता की अनदेखी करने के लिए कहते हैं; लेकिन मेरा मानना है कि यह केवल उन दुर्व्यवहारों के लिए एक अतिशयोक्ति है जो वे पेनी-वार और पाउंड-मूर्ख प्रोग्रामर द्वारा अभ्यास किए जा रहे हैं, जो अपने "अनुकूलित" कार्यक्रमों को डिबग या बनाए नहीं रख सकते हैं। स्थापित इंजीनियरिंग में एक 12% सुधार को आसानी से प्राप्त किया जाता है, जिसे कभी भी सीमांत नहीं माना जाता है; और मेरा मानना है कि सॉफ्टवेयर इंजीनियरिंग में समान दृष्टिकोण होना चाहिए। बेशक, मैं एक-शॉट वाली नौकरी पर इस तरह के अनुकूलन करने से परेशान नहीं होता, लेकिन जब यह गुणवत्ता कार्यक्रम तैयार करने का सवाल है, तो मैं खुद को ऐसे उपकरणों तक सीमित नहीं रखना चाहता जो मुझे ऐसी क्षमता से वंचित करते हैं।

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

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

पिछले पृष्ठ से एक और अच्छा सा:

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

— माइकल शॉ
स्रोत

20

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

सामान्य तौर पर, मुझे लगता है कि शुरुआती सूक्ष्म अनुकूलन एक बुरा विचार हो सकता है। हालांकि, मैक्रो-ऑप्टिमाइज़ेशन (ओ (एन ^ 2) के बजाय ओ (लॉग एन) एल्गोरिदम चुनने जैसी चीजें अक्सर सार्थक होती हैं और उन्हें जल्दी किया जाना चाहिए, क्योंकि यह ओ (एन ^ 2) एल्गोरिदम लिखने के लिए बेकार हो सकता है) फिर इसे O (लॉग एन) दृष्टिकोण के पक्ष में पूरी तरह से फेंक दें।

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

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

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

और डेवलपर्स को डेटा संरचनाओं और एल्गोरिदम के टूलबॉक्स से परिचित होना चाहिए ताकि वे आसानी से नौकरी के लिए सही उपकरण का उपयोग कर सकें।

बहुत ज्ञान और एक व्यक्तिगत टूलबॉक्स होने से आप लगभग आसानी से अनुकूलन कर सकते हैं। एक अनुकूलन में बहुत प्रयास करना जो अनावश्यक हो सकता है वह बुराई है (और मैं एक बार से अधिक उस जाल में गिरने का स्वीकार करता हूं)। लेकिन जब अनुकूलन किसी सरणी के बजाय सेट / हैशटेबल को चुनना या स्ट्रिंग [] के बजाय डबल [] में संख्याओं की एक सूची को संग्रहीत करना जितना आसान है , तो क्यों नहीं? मैं यहां नथ से असहमत हो सकता हूं, मुझे यकीन नहीं है, लेकिन मुझे लगता है कि वह निम्न-स्तर के अनुकूलन के बारे में बात कर रहा था, जबकि मैं उच्च-स्तरीय अनुकूलन के बारे में बात कर रहा हूं।

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

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

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

— Qwertie
स्रोत

2

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

— क्रश करें

13

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

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

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

— शेन मैक्लेघलिन को दर्शाता है
स्रोत

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

— पॉल डे व्रीज़

2

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

3

शुरू में डिजाइन का अनुकूलन, अंत में कोड का अनुकूलन।

— बीसीएस

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

— तोबी एलेन

1

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

— ओलोफ फोर्शेल

10

वास्तव में मैंने सीखा कि समय से पहले गैर-अनुकूलन अधिक बार सभी बुराई की जड़ है।

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

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

बोच को देखो। यह नरक के समान धीमा है। क्या यह कभी तेज होगा? हो सकता है, लेकिन केवल कुछ प्रतिशत की सीमा में। इसे वर्चुअलाइजेशन सॉफ्टवेयर जैसे VMWare या VBox या QEMU से तुलनात्मक प्रदर्शन कभी नहीं मिलेगा। क्योंकि यह डिजाइन से धीमा है!

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

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

मुझे पता है कि यह वास्तव में आपके विशिष्ट मामले में फिट नहीं है, लेकिन यह सामान्य प्रश्न का उत्तर देता है "क्या समयपूर्व अनुकूलन वास्तव में सभी बुराई की जड़ है?" - स्पष्ट सं।

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

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

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

— gnat
स्रोत

6

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

तो मूल रूप से, हाँ, यह समयपूर्व अनुकूलन की तरह लगता है, लेकिन मैं जरूरी नहीं कि इसे वापस कर दूं जब तक कि यह बग का परिचय नहीं देता है - आखिरकार, अब इसे अनुकूलित किया गया है (!)

— harriyott
स्रोत

आपके कहने का अर्थ है "अधिक सुविधाएँ लिखना" के बजाय "अधिक परीक्षण लिखना", सही है? :)

— ग्रेग हेवगिल

1

अधिक सुविधाएँ अधिक परीक्षणों की ओर

— इशारा करती हैं

एर, हाँ! ठीक यही मेरा मतलब है ...

— harriyott

2

कोड आगे जटिलता का परिचय देता है, और संभवतः सार्वभौमिक रूप से उपयोग नहीं किया जाएगा। इसका समर्थन (और इसी तरह की चीजें) कोड को साफ रखता है।

— पॉल डे व्रीज़

3

मेरा मानना है कि माइक कॉहन ने 'गोल्ड-प्लेटिंग' कोड को कॉल किया है - यानी उन चीजों पर समय बिताना जो अच्छे हो सकते हैं लेकिन आवश्यक नहीं हैं।

उन्होंने इसके खिलाफ सलाह दी।

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

— इल्या कोचेतोव
स्रोत

2

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

— स्कॉट डोरमैन

3

चूंकि कोड को समझने में कोई समस्या नहीं है, इसलिए इस मामले को अपवाद माना जा सकता है।

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

— m_pGladiator
स्रोत

1

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

1

आइटमों की वास्तव में छोटी संख्या के लिए, एस्कॉर्ट के लिए आवश्यक पुनरावृत्ति इसे एक सभ्य बुलबुले की तुलना में धीमी बना सकती है ... हालांकि यह उल्लेख नहीं है कि क्विकॉर्ट्स के मामले में सबसे खराब स्थिति में एक बुदबुदाहट तेज है (अर्थात् एक सॉर्ट सूची को त्वरित करते हुए)

— वर्कमैड 3

हाँ, लेकिन यह सिर्फ एक उदाहरण है कि अलग-अलग जरूरतों के लिए एल्गोरिदम का चयन कैसे किया जाता है?)

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

2

एक डिफ़ॉल्ट सॉर्ट का मेरा विचार है जो कुछ भी लाइब्रेरी मुझे देती है (qsort (), .sort (), (सॉर्ट ...), जो भी हो)।

— डेविड थॉर्नले

3

मैंने पाया है कि समयपूर्व अनुकूलन के साथ समस्या ज्यादातर तब होती है जब मौजूदा कोड को तेजी से लिखने के लिए फिर से लिखना पड़ता है। मैं देख सकता हूं कि पहली बार में कुछ जटिल अनुकूलन लिखने में समस्या कैसे हो सकती है, लेकिन ज्यादातर मैं समय से पहले अनुकूलन को अपने बदसूरत सिर को ठीक करने में देखता हूं जो ठीक नहीं है (जिसे जाना जाता है) टूट गया।

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

यह कोड में परिणाम है कि (बुरा) समझने के लिए कठिन है और काम पर बहुत समय जल रहा है कि शायद उपयोगी (बुरा) नहीं है।

— jhocking
स्रोत

3

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

इसलिए, बहुत मौलिक डिजाइन और कार्यान्वयन की खामियां जो "प्रोटो-टाइप" में बहुत कम या कोई चिंता का विषय थीं, उत्पादों की लंबी अवधि की सफलता (और कंपनियों) के लिए प्रमुख ठोकरें बन गईं।

आपका ग्राहक डेमो आपके लैपटॉप पर XML DOM, SQL एक्सप्रेस और बहुत से क्लाइंट-साइड कैश्ड डेटा को देख और प्रदर्शन कर सकता है। यदि आप सफल होते हैं तो उत्पादन प्रणाली संभवत: जलने से दुर्घटनाग्रस्त हो जाएगी।

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

जब कोई कार्यकुशल कोड (C ++, VB, T-SQL या अन्यथा) नहीं लिखने के लिए एक बहाने के रूप में कहावत को दोहराता है, या डेटा स्टोर को ठीक से डिजाइन नहीं करने के लिए, या शुद्ध कार्य वास्तुकला पर विचार नहीं करने के लिए, तो IMO वे केवल प्रदर्शन कर रहे हैं हमारे काम की वास्तविक प्रकृति की बहुत उथली समझ। रे

— रे
स्रोत

1

Haha, या जब तीन उपयोगकर्ताओं के साथ डेमो एक हजार के साथ 1.0 जारी करता है।

— ओलोफ फोर्सशेल

1

मुझे लगता है कि यह इस बात पर निर्भर करता है कि आप "समय से पहले" कैसे परिभाषित करते हैं। जब आप लिख रहे हों तो निम्न-स्तर की कार्यक्षमता को त्वरित बनाना स्वाभाविक नहीं है। मुझे लगता है कि वह बोली की गलतफहमी है। कभी-कभी मुझे लगता है कि बोली कुछ और योग्यता के साथ कर सकती है। मैं हालांकि पठनीयता के बारे में m_pGladiator की टिप्पणियां प्रतिध्वनित करूंगा।

— डोमिनिक रॉजर
स्रोत

1

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

कुछ मामलों में आप दक्षता या प्रदर्शन (कथित या वास्तविक) के लिए डिज़ाइन कर सकते हैं - एक उपयुक्त एल्गोरिथ्म का चयन करना या उपयोगकर्ता इंटरफ़ेस डिज़ाइन करना ताकि पृष्ठभूमि के लिए कुछ महंगे ऑपरेशन हो सकें। कई मामलों में, हॉटस्पॉट निर्धारित करने के लिए प्रोफाइलिंग या अन्य संचालन से आपको 10/90 का लाभ मिलेगा।

इसका एक उदाहरण मैं वर्णन कर सकता हूं वह डेटा मॉडल है जो मैंने एक बार कोर्ट केस मैनेजमेंट सिस्टम के लिए किया था जिसमें लगभग 560 टेबल थे। इसे सामान्यीकृत किया जाने लगा ('खूबसूरती से सामान्यीकृत' एक निश्चित बड़ी -5 फर्म से सलाहकार के रूप में) और हमें केवल इसमें असामान्य डेटा के चार आइटम डालने थे:

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

यह (उस समय) ऑस्ट्रेलेशिया का सबसे बड़ा J2EE प्रोजेक्ट था - अच्छी तरह से डेवलपर के 100 साल से अधिक का समय - और इसमें डेटाबेस स्कीमा में 4 नामांकित आइटम थे, जिनमें से एक वास्तव में बिल्कुल भी नहीं था।

— ConcernedOfTunbridgeWells
स्रोत

1

समयपूर्व अनुकूलन सभी बुराई की जड़ नहीं है, यह सुनिश्चित है। हालाँकि इसमें कुछ कमियाँ हैं:

आप विकास के दौरान अधिक समय निवेश करते हैं
आप इसका परीक्षण करने में अधिक समय लगाते हैं
आप बग्स को ठीक करने में अधिक समय लगाते हैं जो अन्यथा नहीं होगा

समय से पहले अनुकूलन के बजाय, कोई भी दृश्यता परीक्षण कर सकता है, यह देखने के लिए कि क्या बेहतर अनुकूलन की वास्तविक आवश्यकता है।

— रेव्स , 2 उपयोगकर्ता 74% Herr_Alien
स्रोत

1

"पीएमओ" (आंशिक बोली, जो है) का पालन करने वालों में से अधिकांश का कहना है कि अनुकूलन मापन पर आधारित होना चाहिए और माप बहुत अंत तक नहीं किया जा सकता है।

बड़ी प्रणालियों के विकास से यह मेरा अनुभव भी है कि प्रदर्शन परीक्षण बहुत अंत में किया जाता है, क्योंकि विकास पूरा होने के करीब है।

अगर हम इन लोगों की "सलाह" का पालन करते हैं, तो सभी प्रणालियां धीरे-धीरे धीमी हो जाएंगी। वे महंगे होने के साथ-साथ उनके हार्डवेयर की जरूरत मूल रूप से परिकल्पित की तुलना में बहुत अधिक होंगे।

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

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

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

पीएमओ क्या हो सकता है या नहीं हो सकता है पर इस उत्कृष्ट टुकड़े की जाँच करें ।

— ओलोफ फोर्शेल को संशोधित करता है
स्रोत