पहले डेवलपर को पठनीयता या प्रदर्शन के लिए लक्ष्य बनाना चाहिए? [बन्द है]


82

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

int SimpleMultiplyBy2(int x)
{
    return x * 2; 
}

तथा

int FastMultiplyBy2(int x)
{
    return x << 1;
}

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

एक डेवलपर के रूप में, जो प्रारंभिक प्रयास के रूप में बेहतर होगा?


थोड़ा कठोर। एक चिंता के बारे में अच्छा सवाल जो हम सभी के पास कई बार होता है। +1
Inisheer

3
यह उदाहरण स्पष्ट रूप से वंचित और तुच्छ है। आपके पास वास्तव में हार्ड-कोडित गुणक के साथ एक फ़ंक्शन नहीं होगा।
जॉनएमसीजी

1
मुद्दा यह है कि मैं बहुत सारे प्रश्न देख रहा हूँ जैसे "क्या <= से बेहतर प्रदर्शन करता है?" यह गलत प्रश्न है - सही (पहला) प्रश्न जो मुहावरेदार या पारंपरिक है, फिर प्रदर्शन के बारे में चिंता करें।
जॉनएमसीजी

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

2
@OutlawLemur मैं इससे अवगत हूं। लेकिन कुछ लोग पूछते हैं कि क्या यह बेहतर होगा, उदाहरण के लिए, <या <= का उपयोग करके छोरों का निर्माण करें (बाद वाले मामले में तुलनात्मक मूल्य पहले से बढ़ाए जा रहे हैं)।
जॉनएमसीजी

जवाबों:


109

तुम चूक गए।

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

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


यह दूर और सबसे अच्छा जवाब यहाँ है। एल्गोरिथ्म Tweak, कोड नहीं। सूक्ष्म परिवर्तनों के साथ, मैं एक एस्ट्रोस्टेनेस की छलनी छलनी को अन्यथा समान C ++ संस्करण से बेहतर बना सकता हूं। (एटकीज की छलनी नहीं, मेरी अपनी विधि।)
पीटर

2
बहुत बुरा आप पसंदीदा प्रतिक्रिया नहीं कर सकते। :)
सैंडर डेविडजी

59

IMO स्पष्ट पठनीय संस्करण पहले, जब तक कि प्रदर्शन को मापा नहीं जाता है और तेज़ संस्करण की आवश्यकता होती है।


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

46

डॉन नथ से ले लो

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


बोली डॉन से नहीं, बल्कि होरे से है। डॉन ने इसे लोकप्रिय बना दिया। विकिपीडिया की जाँच करें।
कोहरलर्म

1
और यह पूरे अनुच्छेद से एक खंड का एक चयनात्मक उद्धरण है , जिसमें कुछ बहुत महत्वपूर्ण योग्यताएं हैं।
user207421

19

पठनीयता 100%

यदि आपका कंपाइलर आपके लिए "x * 2" => "x << 1" ऑप्टिमाइज़ेशन नहीं कर सकता है - एक नया कंपाइलर प्राप्त करें!

यह भी याद रखें कि आपके कार्यक्रम का 99.9% समय उपयोगकर्ता इनपुट के लिए, डेटाबेस प्रश्नों की प्रतीक्षा और नेटवर्क प्रतिक्रियाओं की प्रतीक्षा में व्यतीत होता है। जब तक आप कई बार 20 बिलियन बार कर रहे हैं, यह ध्यान देने योग्य नहीं है।


8

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


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

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

@WolfmanDragon, आप किस नरक की बात कर रहे हैं? "* 2" एक लूप क्यों उत्पन्न करेगा? जब मैं इसे "gcc -O2 -s" के साथ आज़माता हूं, तो मुझे दोनों मामलों में Addl निर्देश मिलते हैं।
पॉल टॉम्बलिन

1
यदि आपका कंपाइलर उस फ़ंक्शन में एक लूप बनाता है, तो मैं आपको एक और कंपाइलर प्राप्त करने की सलाह दूंगा!
मार्टिन विलकंस


8

पठनीयता।

प्रदर्शन के लिए कोडिंग में चुनौतियों का खुद का सेट है। जोसेफ एम। न्यूकमर ने इसे अच्छी तरह से कहा

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

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


5

पठनीयता। ऑप्टिमाइज़ करने का समय तब होता है जब आप बीटा टेस्टिंग के लिए आते हैं। अन्यथा आप वास्तव में कभी नहीं जानते कि आपको समय बिताने के लिए क्या चाहिए।


5

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

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


4

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


4

एक स्पष्टीकरण के साथ एक टिप्पणी वहाँ डाल पठनीय और तेजी से होगा।

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


3

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

आपका सबसे अच्छा दांव कोड के आसपास (या इसी तरह के सफल अनुप्रयोगों में) यह देखने के लिए है कि अन्य डेवलपर्स यह कैसे करते हैं।


3

उपयोग << एक माइक्रो अनुकूलन द्वारा होगा। तो होरेस (नॉट्स नॉट) रूल:

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

लागू होता है और आपको पहले से अधिक पठनीय संस्करण का उपयोग करना चाहिए।

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


3

दोनों। आपका कोड दोनों को संतुलित करना चाहिए; पठनीयता और प्रदर्शन। क्योंकि किसी एक की अनदेखी करने से प्रोजेक्ट का ROI खराब हो जाएगा, जो दिन के अंत में आपके बॉस के लिए मायने रखता है।

खराब पठनीयता के परिणामस्वरूप स्थिरता में कमी आती है, जिसके परिणामस्वरूप रखरखाव पर अधिक संसाधन खर्च होते हैं, जिसके परिणामस्वरूप कम आरओआई होता है।

खराब प्रदर्शन के परिणामस्वरूप घटे हुए निवेश और ग्राहक आधार में कमी आती है, जिसके परिणामस्वरूप कम आरओआई मिलता है।


2

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


2

यदि आप अपने कोड की पठनीयता के बारे में चिंतित हैं, तो अपने आप को यह याद दिलाने में संकोच न करें कि आप क्या और क्यों कर रहे हैं।


2

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

ऐसा कहने के बाद, आप हमेशा उन टिप्पणियों को डाल सकते हैं जहाँ चालाक कोडिंग में स्पष्टीकरण की आवश्यकता होती है।


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

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

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

2

मैं Google पर काम नहीं करता इसलिए मैं बुराई विकल्प के लिए जाऊंगा। (अनुकूलन)

जॉन बेंटले के "प्रोग्रामिंग पर्ल" के अध्याय 6 में, वह बताता है कि कैसे एक सिस्टम में 6 अलग-अलग डिज़ाइन स्तरों पर अनुकूलन करके 400 गुना गति थी। मेरा मानना ​​है कि इन 6 डिजाइन स्तरों पर प्रदर्शन की परवाह न करके, आधुनिक कार्यान्वयनकर्ता अपने कार्यक्रमों में धीमेपन के परिमाण के 2-3 आदेश आसानी से प्राप्त कर सकते हैं।


1

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

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

लेकिन n << C जैसे अनुकूलन आमतौर पर किसी भी बिंदु पर बदलने के लिए उपेक्षित और तुच्छ होते हैं। कोड बनाना पठनीय नहीं है।


1

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


1

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


1

यह अनुमान है कि सॉफ्टवेयर की लागत का लगभग 70% रखरखाव में है। पठनीयता एक प्रणाली को बनाए रखने के लिए आसान बनाता है और इसलिए अपने जीवन में सॉफ्टवेयर की लागत को कम करता है।

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

पठनीयता का त्याग करने से पहले, सोचें "क्या मैं (या आपकी कंपनी) अतिरिक्त लागत से निपटने के लिए तैयार हूं जिसे मैं इसके द्वारा सिस्टम में जोड़ रहा हूं?"


1

जैसा कि लगभग सभी ने अपने जवाब में कहा, मैं पठनीयता का पक्षधर हूं । मेरे द्वारा चलाए जा रहे 100 में से 99 प्रोजेक्ट्स के लिए कोई कठिन प्रतिक्रिया समय की आवश्यकता नहीं है, इसलिए यह एक आसान विकल्प है।

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

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


1

पठनीयता FIRST लक्ष्य है।

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

केवल तकनीक है कि विकास में एक सांख्यिकीय महत्वपूर्ण अंतर था ...

प्रोग्राम कोड में BLD LINES एड करना।

उन पूर्व-संरचित, पूर्व-वस्तु उन्मुख कोड में पठनीयता में सुधार इन अध्ययनों में एकमात्र तकनीक थी जिसने उत्पादकता में सुधार किया।

==============

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

1970 के दशक के उत्तरार्ध के सॉफ़्टवेयर टूल्स (1976) और सॉफ़्टवेयर टूल इन पीएएससीएएल (1981) में उनकी ऐतिहासिक पुस्तकों में केर्निगन और प्लॉगर ने टॉप डाउन डिज़ाइन का उपयोग करके संरचित कार्यक्रम बनाने के तरीके दिखाए। उन्होंने टेक्स्ट प्रोसेसिंग प्रोग्राम बनाए: एडिटर, सर्च टूल, कोड प्री-प्रोसेसर।

जब पूरा पाठ तैयार करने का कार्य आरंभ किया गया था, तो उन्होंने पाया कि प्रसंस्करण का अधिकांश समय तीन रूटीनों में बिताया गया था, जो पाठ इनपुट और आउटपुट का प्रदर्शन करते थे (मूल पुस्तक में, io फ़ंक्शन ने 89% समय लिया था। पास्कल पुस्तक में, ये कार्य करते हैं। भस्म 55%!)

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


1

पहले पठनीयता। लेकिन पठनीयता से भी अधिक सरलता है, खासकर डेटा संरचना के संदर्भ में।

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

इसकी जांच करें


1

यदि कोई पठनीयता नहीं है, तो जब आपको वास्तव में इसकी आवश्यकता होगी, तो प्रदर्शन में सुधार लाना बहुत कठिन होगा।

प्रदर्शन में केवल तभी सुधार किया जाना चाहिए जब आपके कार्यक्रम में कोई समस्या हो, इस वाक्य रचना के बजाय कई जगह एक बोतल गर्दन होगी। कहते हैं कि आप 1ns सुधार कर रहे हैं << पर एक लेकिन 10 मिनट IO समय पर ध्यान नहीं दिया।

इसके अलावा, पठनीयता के बारे में, एक पेशेवर प्रोग्रामर को कंप्यूटर विज्ञान की शर्तों को पढ़ने / समझने में सक्षम होना चाहिए। उदाहरण के लिए, हम एक विधि नाम रख सकते हैं, बजाय इसके कि हमें putTJJobInWorkQueue कहना है।


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

0

पहले पठनीयता के लिए लिखें, लेकिन पाठकों से प्रोग्रामर बनने की अपेक्षा करें । अपने या अपने नमक के लायक किसी भी प्रोग्रामर को एक बहुतायत और एक बिटशिफ्ट के बीच अंतर पता होना चाहिए, या टर्नरी ऑपरेटर को पढ़ने में सक्षम होना चाहिए, जहां यह उचित रूप से उपयोग किया जाता है, एक जटिल एल्गोरिथ्म को देखने और समझने में सक्षम है (आप अपने कोड को सही बता रहे हैं? ), आदि।

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


0

मैं कहूँगा पठनीयता के लिए जाना।

लेकिन दिए गए उदाहरण में, मुझे लगता है कि दूसरा संस्करण पहले से ही पठनीय है, क्योंकि फ़ंक्शन का नाम बताता है कि फ़ंक्शन क्या चल रहा है।

अगर हमारे पास हमेशा ऐसे कार्य होते हैं जो हमें बताते हैं, तो वे क्या करते हैं ...


0

प्रोसेसर समय के एक घंटे में कितना खर्च होता है?

एक घंटे के प्रोग्रामर के समय में कितना खर्च होता है?


1
अंत उपयोगकर्ता के समय का एक घंटा कितना खर्च होता है? अब पारस्परिक रूप से उपयोगकर्ताओं की संख्या से।
gbjbaanb

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

0

IMHO दोनों चीजों का कोई लेना देना नहीं है। आपको पहले उस कोड के लिए जाना चाहिए जो काम करता है, क्योंकि यह प्रदर्शन से अधिक महत्वपूर्ण है या यह कितना अच्छा है। पठनीयता के बारे में: आपका कोड हमेशा किसी भी मामले में पठनीय होना चाहिए।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.