"समय से पूर्व अनुकूलन सभी बुराई की जड़ है" के बारे में गलत धारणाओं से कैसे निपटें?


26

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

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

पिछले प्रयास

कुछ बार, मैंने यह समझाने के लिए कि डोनाल्ड नथ से पूरा उद्धरण देने की कोशिश की है कि "समय से पहले का अनुकूलन बुरा है" "सभी अनुकूलन खराब है":

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

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


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

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

6
@errantlinguist: यदि आपने कोड के उस भाग के साक्ष्य को आवेदन के लिए एक महत्वपूर्ण प्रदर्शन समस्या के रूप में प्रस्तुत किया है, और आवेदन पूरी तरह से धीमा है, तो इसकी आवश्यकता है, और उन्होंने अभी भी कोड को संशोधित करने की आवश्यकता से इनकार किया है, तो यह नहीं है ' टी मामला आप ऐसे लोगों से निपट रहे हैं जो साक्ष्य-आधारित तर्क के लिए अभेद्य हैं, और इस प्रकार अनुचित हैं।
निकोल बोलस

6
@errantlinguist: प्रमुख प्रश्न: क्या ग्राहकों की शिकायत थी कि उस क्षेत्र में आवेदन धीमा था?
रोबोट

5
मैं बंद करने के लिए मतदान कर रहा हूं क्योंकि ओपी स्पष्ट रूप से केवल किसी वास्तविक प्रश्न के उत्तर के बजाय किसी राय को मान्य करने के लिए देख रहा है। मुझे नहीं लगता कि यह (या) वर्कप्लेस पर खुला रहना चाहिए। या तो।
ब्लूराजा -

जवाबों:


35

ऐसा लगता है कि आप पहले "शुद्ध भोले कार्यान्वयन" को आज़माने के लिए शॉर्टकट की तलाश कर रहे हैं, और सीधे "अधिक परिष्कृत समाधान लागू करें" क्योंकि आप पहले से जानते हैं कि भोली कार्यान्वयन ऐसा नहीं करेगा "। दुर्भाग्य से, यह शायद ही कभी काम करेगा - जब आपके पास यह साबित करने के लिए कठिन तथ्य या तकनीकी तर्क नहीं हैं कि अनुभवहीन कार्यान्वयन बहुत धीमा है या होगा, तो आप शायद सबसे गलत हैं, और आप जो कर रहे हैं वह समय से पहले अनुकूलन है। और नुथ के साथ बहस करने की कोशिश करना एक कठिन तथ्य होने के विपरीत है।

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

"भोले का कार्यान्वयन O (n³) होगा, और n 100.000 से बड़ा है; कुछ दिन चलेगा, जबकि भोले-भाले कार्यान्वयन O (n) में चलेगा, जिसमें कुछ ही मिनट लगेंगे"

केवल ऐसे तर्कों के साथ आप यह सुनिश्चित कर सकते हैं कि आपका अनुकूलन समय से पहले न हो।

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

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

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


15
@errantlinguist: शायद मैंने खुद को स्पष्ट नहीं किया, या यह बस वह नहीं है जो सुनना चाहता था? मेरी सलाह है: "3%" या "97%" के बारे में नुथ के * दार्शनिक तर्क "का उपयोग करने की कोशिश न करें। इसे तथ्यात्मक रखें, अन्यथा आपके सहकर्मी शायद सबसे सही हैं कि आपके प्रदर्शन तर्क अनुचित हैं।
डॉक्टर ब्राउन

4
@errantlinguist: आपने कार्ल बेलेफेल्ड के उत्तर में अपनी टिप्पणी में वर्णित मामले में, "प्रदर्शन" का उपयोग करने की आवश्यकता के बिना अपनी तरफ से सभी तर्क दिए हैं। मैं एक कदम और आगे जाऊंगा, यदि आप इस तरह के मामले में प्रदर्शन के बारे में बहस करते हैं, तो आप एक जबरदस्त गलती करते हैं, क्योंकि आपके सहकर्मी सही हैं: प्रदर्शन आम तौर पर वहां मायने नहीं रखता है। सादगी, पठनीयता, स्थिरता, कोड की कम पंक्तियों के बारे में तर्क दें, लेकिन प्रदर्शन के बारे में नहीं (!), एक साइड नोट के रूप में भी नहीं। उन्हें आप के खिलाफ नथ का उपयोग करने का अधिकार नहीं देते।
डॉक ब्राउन

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

2
@errantlinguist: मुझे यकीन नहीं है कि आप उस निष्कर्ष पर कैसे पहुँचे। डॉक्टर ब्राउन का जवाब पूरी तरह से स्पष्ट लगता है: आप इन अनुत्पादक तर्कों के माध्यम से काटते हैं कि आप अपने सहकर्मियों के साथ तथ्यात्मक बयानों पर चिपके हुए हैं जो स्वीकार्य नहीं है।
jl6

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

18

अपने आप से यह पूछें:

  • क्या सॉफ्टवेयर प्रदर्शन के विनिर्देशन को पूरा नहीं कर रहा है?
  • क्या सॉफ़्टवेयर के पास कोई प्रदर्शन समस्या है?

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

मुझे लगता है कि बोली का मुख्य बिंदु है, अगर आपको कोई समस्या नहीं है, तो समय के साथ अनावश्यक अनुकूलन न करें और ऊर्जा कहीं और खर्च की जा सकती है। एक संभावित व्यवसाय से, यह सही समझ में आता है।

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

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


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

7
मैं इसके अलावा सभी से सहमत हूं "केवल कुछ विशेष उद्योगों में गति वास्तव में महत्वपूर्ण है।" मुझे लगता है कि आप उस सॉफ़्टवेयर की मात्रा को कम आंकते हैं जिसमें ग्राहक के दृष्टिकोण से प्रदर्शन के मुद्दे हैं।
रोबोट

@StevenBurnap: Yep-- वहाँ जंगली में वेब अनुप्रयोग हैं जो वास्तव में धीमा नहीं हैं ? - मैं एक ही विज्ञान में देखना चाहता हूं।
इरैंटलिंगुइस्ट

1
google.com बहुत तेज है। :-P
रोबोट

EDGE मोबाइल कनेक्शन पर google.com का उपयोग करने का प्रयास करें। हाँ, यह एक हास्यास्पद मामला है, लेकिन यह निश्चित रूप से बहुत तेज़ नहीं होगा । ;) (पुन: वास्तव में अभिप्रेत नहीं है
त्रुटिपूर्णवादी

7

ऐसे लोगों के साथ कैसे काम करें जो एक चर्चा को मिनट करते हैं जो इसे प्रदर्शन के साथ करना है?

साझा सिद्धांतों से शुरू करें जो आपके समूह की रणनीतिक दिशा पर आधारित हैं।

मेरे सिद्धांत:

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

यदि आपके उपभोक्ता ग्राहक हैं, तो आपके ग्राहक आपको बताएंगे कि क्या आपको तेज कोड की आवश्यकता है।

हालांकि, ज्ञात हैं, कोड में demonstrably बेहतर विकल्प है कि एक बना सकते हैं। मैं इसके बजाय कई कारणों से अपने पहले मसौदे में इसे सही करूंगा:

  1. अगर मुझे यह पहली बार सही लगता है, तो मैं कार्यान्वयन के बारे में भूल सकता हूं (जानकारी छिपाने का लाभ उठा रहा हूं), और मैं TODOs के साथ अपने कोड को अव्यवस्थित नहीं करता।
  2. अन्य (विशेषकर जो केवल नौकरी पर सीखते हैं) इसे सही तरीके से देखते हैं, और वे उसी शैली को सीखते हैं और आगे बढ़ने वाले कोड की इसी शैली का उपयोग करते हैं। इसके विपरीत, अगर वे मुझे इसे गलत तरीके से करते हुए देखते हैं, तो वे इसे गलत तरीके से भी करेंगे।

अनुकूलन की आवश्यकता को सही मानते हुए

यह मानते हुए कि यह आपके कोड का सही मायने में महत्वपूर्ण हिस्सा है, जिसे अनुकूलन की आवश्यकता है, आप स्लेमियल पेंटर के दृष्टांत को बता सकते हैं , या शेष उद्धरण पर जोर दे सकते हैं:

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

अतिरिक्त जटिलता की लागत तौलना

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

नेतृत्व

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

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


6

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

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

आपको इसे "अनुकूलन" कहने की ज़रूरत नहीं है, आप इसे "फिक्सिंग बग" कह सकते हैं, क्योंकि यह बग की परिभाषा के अनुसार है यदि कार्यान्वयन आवश्यकताओं के अनुरूप विफल रहता है।

आमतौर पर, अनुकूलन के संबंध में दो संभावनाएँ हैं:

  1. अनुकूलित कोड भी छोटा है, समझने में आसान है और बनाए रखने में आसान है।

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

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


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

@DocBrown: बेशक, लेकिन किसी भी मामले में यह ग्राहक है जो तय करता है कि यह बहुत धीमा है या नहीं, डेवलपर नहीं।
जाकबीस

मैं कभी भी व्यावसायिक आवश्यकताओं के बारे में नहीं आया हूँ जो स्पष्ट रूप से राज्य के प्रदर्शन की आवश्यकताओं को बताती हैं।
इलैंटलिंग्लिस्ट

@errantlinguist: मेरे अनुभव में यह ऑनलाइन दुकानों की तरह ग्राहक केंद्रित व्यवसायों में बहुत आम है। लेकिन एक कंपनी में आंतरिक उपयोग के लिए उपकरण और अनुप्रयोगों के लिए, उपयोगकर्ता अनुभव आमतौर पर परियोजना के मालिक के लिए चिंता का विषय नहीं है।
जाकबीस

4

मुझे लगता है कि संदर्भ में पूरा उद्धरण शिक्षाप्रद है। मैं इस विषय पर रेडिट पर किए गए एक पोस्ट से कॉपी करूंगा:

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

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

- डोनाल्ड नुथ, स्ट्रक्चर्ड प्रोग्रामिंग टू स्टेट्स टू गो , एसीएम कम्प्यूटिंग सर्वे, खंड 6, संख्या 4, दिसंबर 1974, पृष्ठ.268

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

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


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

3

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

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


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

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

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

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

2

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

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

यह "समय से पहले अनुकूलन" में "समय से पहले" है। जब यह "समय से पहले" नहीं है? जब ग्राहक आपको बताते हैं "यह बहुत धीमा है, तो इसे ठीक करें!" जब आप कोड में खुदाई करते हैं और इसे तेज करने का प्रयास करते हैं।

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


इसका मतलब यह नहीं है कि आपको अपना दिमाग बंद कर देना चाहिए। इसका मतलब यह नहीं है कि आपको 10,000 ग्राहक रिकॉर्ड एक एकल लिंक की गई सूची में रखने चाहिए। > जबकि मैं आपसे 100% सहमत हूं, लेकिन मैंने वास्तव में उस तरह से जुड़ी हुई सूचियों को देखा है, और कहा गया है कि "इसे स्पर्श न करें"।
इरैंटलिंग्लिस्ट

अच्छी जानकारी के दौरान, यह वास्तव में मेरे सवाल का जवाब नहीं देता है कि ऐसे लोगों के साथ कैसे काम करना है जो एक मिनट चर्चा करते हैं जो इसे प्रदर्शन के साथ करना है।
इरैंटलिंग्लिस्ट

3
अफसोस की बात है कि, "अकेले जुड़ी हुई सूची" चीज एक यादृच्छिक उदाहरण नहीं थी, लेकिन कुछ ऐसा था जिसे मैं व्यक्तिगत रूप से चलाता था।
को रोबोट

1

आप या तो चीजों को गलत तरीके से कर सकते हैं, या चीजों को सही तरीके से कर सकते हैं।

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

यह जरूरी नहीं है कि आप समय से पहले अनुकूलन करें क्योंकि आपको पता है कि यह भविष्य में मदद करेगा या बी) यह जानकर कि उप-मार्ग का रास्ता सड़क की समस्याओं को जन्म देगा। यह वास्तव में एक शतरंज के खेल की तरह है।

मुझे लगता है कि लोग गलत करने के बजाय चीजों को सही करना चाहते हैं। जब आप अपने साथियों के साथ वैकल्पिक रणनीतियों पर चर्चा करते हैं तो इसका उपयोग करें।


5
कभी भी "गलत तरीका" या "सही तरीका" नहीं है। आमतौर पर अनंत तरीके होते हैं जो एक निरंतरता में चलते हैं "माय गॉड, यह कैसे चलता है !?" "जॉन कार्मैक और डोनाल्ड नुथ जोड़ी प्रोग्रामिंग के दौरान इसे बेहतर नहीं बना सके"।
रोबोट

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

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

1

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

वास्तविक प्रोग्रामिंग पर अधिक ध्यान केंद्रित किया गया है, कुछ समय के लिए लंबे समय के तर्कों पर समय बर्बाद न करें जो आपको बस एक तीव्र एहसास है "तेज"। यदि आप किसी व्यक्ति को वेब ऐप में अनुरोध के अनुसार एक बार एक विधि लिखते हुए देखते हैं और इसमें O (n ^ 2) समय की जटिलता है, तो आप जानते हैं कि यह वास्तव में एक O (लॉग (n)) समय की समस्या है, तो यकीन है, अगर यह ऐसा है कोई दिमाग नहीं, आगे बढ़ो।

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


मैं उत्तर को संपादित करता हूं और fleshed सामान को थोड़ा और बाहर करता हूं, क्या downvoter कुछ प्रतिक्रिया जोड़ सकता है? :)
सारा

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

मूल रूप से जो मैं पिछले दो पैराग्राफ में प्राप्त करना चाहता हूं वह है "उन अनुकूलन भी मायने नहीं रखते हैं"। उस मामले में, अपने झगड़े को चुनना बेहतर है।
सारा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.