क्या मॉड्यूलर प्रोग्रामिंग कम्प्यूटेशन समय को प्रभावित करता है?

Question

हर कोई कहता है कि मुझे अपना कोड मॉड्यूलर बनाना चाहिए, लेकिन क्या यह कम कुशल नहीं है अगर मैं कम, बल्कि बड़े तरीकों के बजाय अधिक विधि कॉल का उपयोग करता हूं? उस मामले के लिए जावा, सी, या सी ++ में क्या अंतर है?

मुझे लगता है कि इसे संपादित करना, पढ़ना और समझना आसान है, खासकर एक समूह में। तो कोड tidiness लाभ की तुलना में गणना समय हानि नगण्य है?

Comments

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

— Blrfl

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

— gnat

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

— ग्रेफेड

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

— मैकीज पीचोटका

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

— एसएफ।

Answer 1

हां, यह अप्रासंगिक है।

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

संक्षेप में, सीपीयू पर दया करना पूरी तरह से, 99.99% समय के लिए पूरी तरह से गुमराह करना है। शेष बचे मामलों के लिए, प्रोफाइलरों का उपयोग करें। है न मान लें कि आप उन मामलों देखा जा सकता है - आप नहीं कर सकते।

Comments

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

— होनज़ा ब्रेबेक

+1 केवल "सीपीयू पर दया लेने" की अभिव्यक्ति के लिए, क्योंकि यह समय से पहले अनुकूलन में गलत तरीके से उच्चारण करता है।

— माइकल बोरगवर्ड

अत्यधिक संबंधित: रोजमर्रा की शर्तों में कंप्यूटर कितने तेज़ हैं? "गति" के लिए कुछ फ़ंक्शन कॉल से बचने के लिए अपने रास्ते से बाहर जाना अपने पूरे जीवन के दौरान किसी एक मिनट को बचाने के लिए अपने रास्ते से बाहर जाने के समान है । संक्षेप में: यह विचार करने में लगने वाले समय के लायक भी नहीं है।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

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

— जिमी हॉफ

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

— वेन

Answer 2

निर्भर करता है।

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

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

कई साल पहले, मैं उस समय एक सभ्य प्रोसेसर पर वास्तविक समय की FLIR इमेजरी पर 8-तरह की कनेक्टिविटी ब्लॉब कलरिंग कर रहा था। पहले प्रयास में एक सबरूटीन कॉल का उपयोग किया गया था, और सबरूटीन कॉल ओवरहेड ने प्रोसेसर को जिंदा खा लिया। (4 कॉल प्रति PIXEL x 64K पिक्सल प्रति फ्रेम x 30 फ्रेम प्रति सेकंड = आप इसका पता लगाते हैं)। दूसरे प्रयास ने सब्रूटीन को सी मैक्रो में बदल दिया, जिसमें पठनीयता का कोई नुकसान नहीं था, और सब कुछ गुलाब था।

आपको HARD को देखना होगा कि आप क्या कर रहे हैं और उस वातावरण में जिसमें आप कर रहे हैं।

Comments

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

— केविन -

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

— 23

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

— उवे प्लोनस

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

— डोनाल्ड फेलो

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

— जॉन आर। स्ट्रॉह्म

Answer 3

सबसे पहले: एक उच्च भाषा में कार्यक्रम मनुष्यों द्वारा मशीनों द्वारा नहीं पढ़ा जा रहा है।

इसलिए प्रोग्राम लिखें ताकि आप उन्हें समझ सकें। प्रदर्शन के बारे में मत सोचो (यदि आपको गंभीरता से समस्या आती है तो अपने आवेदन को प्रोफाइल करें और जहां प्रदर्शन की आवश्यकता है, उसे बढ़ाएं)।

यहां तक ​​कि अगर यह सच है कि एक विधि या फ़ंक्शन को कॉल करने से कुछ ओवरहेड हो जाता है तो इससे कोई फर्क नहीं पड़ता। आज संकलक आपके कोड को कुशल मशीन भाषा में संकलित करने में सक्षम होना चाहिए ताकि उत्पन्न कोड लक्ष्य वास्तुकला के लिए कुशल हो। कुशल कोड प्राप्त करने के लिए अपने कंपाइलर के अनुकूलन स्विच का उपयोग करें।

Comments

मैं कहूंगा कि हमें कार्यक्रमों को इस तरह से लिखना चाहिए कि दूसरे उन्हें समझ सकें।

— बार्टलोमिएज लेवांडोव्स्की

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

— उवे प्लोनस

Answer 4

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

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

Answer 5

शायद कोई संगणना लागत नहीं है। आमतौर पर पिछले 10-20 वर्षों के कंपाइलर / जेआईटी या तो फ़ंक्शन पूरी तरह से ठीक रहते हैं। C / C ++ के लिए आमतौर पर यह 'इनलाइन करने योग्य' कार्यों तक ही सीमित होता है (यानी संकलन के दौरान कंपाइलर के लिए फ़ंक्शन की परिभाषा उपलब्ध है - अर्थात यह उसी फ़ाइल के हेडर में है) लेकिन LTO की वर्तमान तकनीक इसे दूर करती है।

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

ऐसे मामलों में भी आपको माइक्रो-ऑप्टिमाइज़ेशन करने से पहले कई बातों पर ध्यान देना चाहिए:

• समस्याएं कहां हैं? आमतौर पर लोगों के पास हॉटस्पॉट खोजने का कठिन समय होता है क्योंकि हम स्रोत कोड को अलग तरीके से पढ़ते हैं। हमारे पास ऑपरेशन के समय का अलग-अलग अनुपात है और हम उन्हें क्रमिक रूप से निष्पादित करते हैं जबकि आधुनिक प्रोसेसर नहीं करते हैं ।
• क्या हर बार कुछ गणना की आवश्यकता है? उदाहरण के लिए यदि आप हजारों में से एक एकल पैरामीटर को बदलते हैं तो आप पूरे मॉडल के बजाय प्रभावित हिस्से की गणना करना चाहते हैं।
• क्या आप इष्टतम एल्गोरिथ्म का उपयोग करते हैं? से बदलें O(n)करने के लिए O(log n)बहुत बड़ा प्रभाव तो कुछ भी आप सूक्ष्म अनुकूलन द्वारा प्राप्त कर सकते हो सकता है।
• क्या आप उचित संरचनाओं का उपयोग करते हैं? कहते हैं कि आप का उपयोग कर रहे हैं Listजब आप की जरूरत है HashSetताकि आप O(n)जब आप कर सकते हैं लुकअप है O(1)।
• क्या आप समानता का कुशलता से उपयोग करते हैं? वर्तमान में भी मोबाइल फोन में 4 कोर या उससे अधिक हो सकते हैं जो थ्रेड्स का उपयोग करने के लिए आकर्षक हो सकते हैं। हालांकि वे एक चांदी की गोली नहीं हैं क्योंकि उनके पास सिंक्रनाइज़ेशन की लागत है (यह उल्लेख नहीं है कि यदि समस्या स्मृति बाध्य है, तो वे वैसे भी कोई मतलब नहीं रखते हैं)।

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

1. जिस प्लेटफ़ॉर्म पर आप काम कर रहे हैं, ठीक वही जानें
2. पता करें कि आप जिस कंपाइलर पर काम कर रहे हैं और वह किस ऑप्टिमाइज़ेशन को करने में सक्षम है और उन ऑप्टिमाइज़ेशन को इनेबल करने के लिए मुहावरेदार कोड कैसे लिखें
3. मेमोरी एक्सेस पैटर्न के बारे में सोचें और आप कितना कैश में फिट हो सकते हैं (सटीक आकार, जिसे आप बिंदु 1 से जानते हैं)।
4. यदि आप गणना करने के लिए बाध्य हैं तो गणना को बचाने के लिए संगणना के पुनर्गठन के बारे में सोचें

---

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

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

Answer 6

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

सबसे पहले; हां, प्रतिरूपकता के लिए, आप आमतौर पर निष्पादन के समय के कुछ स्तर को छोड़ देते हैं। असेंबली कोड में सब कुछ लिखना आपको सबसे अच्छी गति देने वाला है। ने कहा कि...

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

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

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

Answer 7

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

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

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

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