प्रत्याशित अनुकूलन

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

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

विकास के किस चरण में प्रदर्शन पर ध्यान देने का समय है? किस बिंदु पर अनुकूलन समय से पहले हो जाता है और समय पर हो जाता है?

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

एक वर्ष से अधिक समय तक उद्योग में काम करने और एक दर्जन से अधिक परियोजनाओं को पूरा करने के बाद, मैं विश्वास के साथ कह सकता हूं: यह पूरी बकवास है। वास्तव में, सब कुछ पूरी तरह से अलग तरीके से होता है।

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



जब आप किसी प्रॉजेक्ट पर प्रोइलर लगाते हैं तो स्लोगन के तहत लिखा जाता है, "समय से पहले अनुकूलन न कहें!" , आप कुछ ऐसा ही देखने की उम्मीद करते हैं।



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

ज्यादातर मामलों में, प्रोफाइलर आपको यह आकर्षित करेगा:




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

जीवन से कुछ उदाहरण चाहते हैं? कृपया। सुगरसीआरएम व्यवसाय पोर्टल के एक पृष्ठ के लिए न्यूनतम रेंडरिंग का समय लगभग 100 मिलीसेकंड है, यहां तक ​​कि सर्वश्रेष्ठ हार्डवेयर पर भी। वेब अनुप्रयोगों की दुनिया में, यह राज्य की स्थिति किसी को परेशान नहीं करती है (हर कोई लंबे समय से इस तथ्य के आदी हो गया है कि वेब पेज पर प्रत्येक क्लिक कई सेकंड के लिए संसाधित होता है), लेकिन स्थिति इस बिंदु पर पहुंच गई है कि कुछ वेब सेवाओं के लिए संक्षिप्त प्रतिक्रिया समय गंभीर हो गया है प्रतिस्पर्धात्मक लाभ। मैं वास्तव में Rdio इंटरनेट रेडियो को पसंद करता हूं, लेकिन अगर मुझे इसका एक एनालॉग मिल जाता है, जो मुझे पेज स्विचिंग के बीच दूसरी देरी नहीं मिलेगी, तो मैं तुरंत इसे स्विच कर दूंगा।

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

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