मैं सिस्टम स्टूडियो के विज़ुअल स्टूडियो के साथ काम करने में अनुभवी लोगों से पूछना चाहता हूं: ऐसा क्या है जो उन्हें धीमा बनाता है? क्या यह मानव संयम क्षमताओं के भीतर कोडबेस रखने के लिए आवश्यक अमूर्तता की परतों पर परतें हैं? क्या यह कोड की सरासर राशि है जिसे चलाने की आवश्यकता है? क्या यह घड़ी चक्र / स्मृति उपयोग विभाग में (माइंडबॉगलीली विशाल) व्यय पर प्रोग्रामर-समय-बचत दृष्टिकोणों की दिशा में आधुनिक प्रवृत्ति है?
मुझे लगता है कि आप उनमें से एक संख्या का अनुमान लगाते हैं, लेकिन मैं पेशकश करना चाहूंगा कि मैं सबसे बड़ा कारक क्या मानता हूं, एक बड़े बड़े कोडबेस पर काम करना (यह सुनिश्चित नहीं है कि यह विज़ुअल स्टूडियो जितना बड़ा है - कोड की लाखों लाइनों में था श्रेणी और एक हजार प्लगइन्स के बारे में) के बारे में 10 साल के लिए और देख घटना।
यह थोड़ा कम विवादास्पद भी है क्योंकि यह एपीआई या भाषा सुविधाओं या उस जैसी किसी भी चीज़ में नहीं जाता है। वे "लागत" से संबंधित हैं जो "खर्च" के बजाय एक बहस को गति दे सकते हैं, और मैं "खर्च" पर ध्यान केंद्रित करना चाहता हूं।
ढीले समन्वय और विरासत
मैंने देखा कि ढीला समन्वय और एक लंबी विरासत बहुत सारे संचित कचरे को जन्म देती है।
उदाहरण के लिए, मुझे इस कोडबेस में लगभग एक सौ त्वरण संरचनाएं मिलीं, उनमें से कई बेमानी हैं।
हम एक भौतिकी इंजन को तेज करने के लिए एक केडी के पेड़ की तरह होगा, एक नया भौतिकी इंजन के लिए दूसरा जो अक्सर पुराने के समानांतर चल रहा था, हमारे पास विभिन्न जाल एल्गोरिदम के लिए ऑक्ट्रेसेस के दर्जनों कार्यान्वयन होंगे, प्रतिपादन के लिए एक और केडी पेड़। , पिकिंग, आदि आदि। ये सभी बड़े, भारी वृक्ष संरचनाएं हैं जिनका उपयोग खोजों में तेजी लाने के लिए किया जाता है। प्रत्येक व्यक्ति एक सैकड़ों मेगाबाइट को बहुत औसत आकार के इनपुट के लिए मेमोरी के गीगाबाइट तक ले जा सकता है। वे हमेशा तात्कालिक नहीं थे और हर समय उपयोग करते थे, लेकिन किसी भी समय, उनमें से 4 या 5 एक साथ स्मृति में हो सकते हैं।
अब ये सभी उनके लिए खोजों को तेज करने के लिए सटीक समान डेटा संग्रहीत कर रहे थे। आप इसे एनालॉग पुराने डेटाबेस के रूप में कल्पना कर सकते हैं जो अपने सभी क्षेत्रों को एक ही समय में 20 अलग-अलग अनावश्यक मानचित्रों / शब्दकोशों / बी + पेड़ों में संग्रहीत करता है, समान कुंजी द्वारा पहचाना जाता है, और उन सभी को हर समय खोजता है। अब हम मेमोरी और प्रोसेसिंग को 20 गुना कर रहे हैं।
इसके अलावा, अतिरेक के कारण, रखरखाव मूल्य टैग के साथ उनमें से किसी एक को अनुकूलित करने के लिए बहुत कम समय है जो उस के साथ आता है, और यहां तक कि अगर हमने किया, तो इसका आदर्श रूप से केवल 5% प्रभाव होगा।
इस घटना का क्या कारण है? ढीला समन्वय नंबर एक कारण था जो मैंने देखा। टीम के बहुत से सदस्य अक्सर अपने पृथक पारिस्थितिक तंत्र में काम करते हैं, तीसरे पक्ष के डेटा संरचनाओं का विकास या उपयोग करते हैं, लेकिन समान संरचनाओं का उपयोग नहीं करते हुए टीम के अन्य सदस्य उपयोग कर रहे थे, भले ही वे सटीक समान चिंताओं के स्पष्ट रूप से डुप्लिकेट थे।
इस घटना के बने रहने का क्या कारण है? विरासत और अनुकूलता नंबर एक कारण था जो मैंने देखा। चूंकि हमने पहले से ही इन डेटा संरचनाओं को लागू करने की लागत का भुगतान किया था और बड़ी मात्रा में कोड इन समाधानों पर निर्भर थे, इसलिए उन्हें अक्सर कम डेटा संरचनाओं के लिए समेकित करने का प्रयास करना बहुत जोखिम भरा था। भले ही इन डेटा संरचनाओं में से कई वैचारिक रूप से अत्यधिक अनावश्यक थे, वे हमेशा अपने इंटरफेस डिजाइनों में समान के करीब नहीं थे। इसलिए उन्हें प्रतिस्थापित करना एक बड़ा, जोखिम भरा बदलाव होगा क्योंकि विरोध करने से उन्हें स्मृति और प्रसंस्करण समय का उपभोग करना पड़ता है।
मेमोरी क्षमता
आमतौर पर मेमोरी का उपयोग और गति कम से कम थोक स्तर पर संबंधित होती है। आप अक्सर धीमे सॉफ़्टवेयर को स्पॉट कर सकते हैं कि यह मेमोरी को कैसे बढ़ा रहा है। यह हमेशा सच नहीं है कि अधिक मेमोरी मंदी की ओर ले जाती है, क्योंकि "हॉट" मेमोरी क्या मायने रखती है (किस मेमोरी को हर समय एक्सेस किया जा रहा है - यदि कोई प्रोग्राम मेमोरी के एक बोटलोड का उपयोग करता है, लेकिन केवल 1 मेगाबाइट का उपयोग किया जा रहा है समय है, तो यह इतनी बड़ी डील स्पीड-वार नहीं है)।
तो आप बहुत बार मेमोरी उपयोग के आधार पर संभावित हॉग को स्पॉट कर सकते हैं। यदि कोई एप्लिकेशन स्टार्टअप पर सैकड़ों मेगाबाइट मेमोरी में दसियों लेता है, तो यह संभवतः बहुत कुशल नहीं होगा। जब हम इन दिनों DRAM के गीगाबाइट्स हैं, तब मेगाबाइट्स के दसवे छोटे लग सकते हैं, लेकिन सबसे बड़े और धीमे सीपीयू कैश अभी भी मेगाबाइट रेंज में हैं, और सबसे तेज़ अभी भी किलोबाइट रेंज में हैं। नतीजतन, एक प्रोग्राम जो 20 मेगाबाइट्स का उपयोग करता है, बस स्टार्ट अप करने के लिए और कुछ भी नहीं करने के लिए वास्तव में अभी भी हार्डवेयर CPU कैश बिंदु से मेमोरी का "बहुत" उपयोग कर रहा है, खासकर यदि उस मेमोरी के सभी 20 मेगाबाइट्स को बार-बार एक्सेस किया जाएगा और अक्सर कार्यक्रम चल रहा है।
समाधान
मेरे लिए समाधान यह है कि उत्पादों के निर्माण के लिए अधिक समन्वित, छोटी टीमों की तलाश की जाए, जो अपने "खर्च" का हिसाब रख सकें और एक ही सामान को बार-बार "खरीदने" से बचें।
लागत
मैं और अधिक विवादास्पद "लागत" पक्ष में डुबकी लगाऊंगा जो मैंने देखा है एक "खर्च" घटना के साथ एक नन्हा सा। यदि कोई भाषा किसी वस्तु के लिए अपरिहार्य मूल्य टैग के साथ आती है (जैसे कि रनटाइम प्रतिबिंब प्रदान करता है और वस्तुओं की एक श्रृंखला के लिए सन्निहित आवंटन को बाध्य नहीं कर सकता है), तो यह मूल्य टैग बहुत दानेदार तत्व के संदर्भ में महंगा है, जैसे कि एकल Pixelया Boolean।
फिर भी मैं उन कार्यक्रमों के लिए बहुत सारे स्रोत कोड देखता हूं, जो एक भारी भार को संभालते हैं (उदाहरण: ऐसे हजारों से लाखों Pixelया Booleanउदाहरणों के साथ काम करना ) जो इस तरह के दानेदार स्तर पर उस लागत का भुगतान करते हैं।
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग एक तरह का एक्सर्पट कर सकती है। फिर भी यह गलती से "ऑब्जेक्ट्स" प्रति se या OOP की लागत नहीं है, यह बस इतना है कि इस तरह के खर्चों को एक किशोरी तत्व के ऐसे दानेदार स्तर पर भुगतान किया जा रहा है जो लाखों लोगों द्वारा तुरंत किया जा रहा है।
तो यह है कि अन्य "लागत" और "खर्च" घटना मैं देख रहा हूँ। लागत पेनीज़ है, लेकिन पेनीज़ जोड़ते हैं अगर हम एक थोक खरीद के लिए निर्माता के साथ बातचीत करने के बजाय व्यक्तिगत रूप से सोडा के एक लाख डिब्बे खरीद रहे हैं।
यहाँ मेरे लिए समाधान "थोक" खरीद है। वस्तुएं उन भाषाओं में भी पूरी तरह से ठीक हैं, जिनमें हर एक को पेनी के कुछ मूल्य टैग हैं बशर्ते कि यह लागत व्यक्तिगत रूप से एक सोडा कैन के समतुल्य समकक्ष के लिए एक लाख बार भुगतान नहीं की जा रही हो।
समय से पहले अनुकूलन
मुझे यहां इस्तेमाल किए जाने वाले शब्द नथ बहुत पसंद नहीं थे, क्योंकि "समय से पहले अनुकूलन" शायद ही कभी वास्तविक दुनिया के उत्पादन कार्यक्रमों को तेज करता है। कुछ लोग इसकी व्याख्या करते हैं कि जब "नथिंग का शुरुआती अनुकूलन" हुआ था, तो इसका मतलब था कि "सॉफ़्टवेयर पर इसका वास्तविक प्रभाव जानने के लिए उचित ज्ञान / अनुभव के बिना अनुकूलन करना अधिक पसंद है।" यदि कुछ भी हो, तो सही समय से पहले अनुकूलन का व्यावहारिक प्रभाव अक्सर सॉफ्टवेयर को धीमा बनाने वाला होता है , क्योंकि स्थिरता में गिरावट का मतलब है कि महत्वपूर्ण पथों के अनुकूलन के लिए बहुत कम समय है जो वास्तव में मायने रखता है ।
यह अंतिम घटना है जिसे मैंने देखा, जहां डेवलपर्स सोडा की एक भी कैन की खरीद पर पेनी को बचाने के लिए पहुंचते हैं, फिर कभी नहीं खरीदा जा सकता है, या इससे भी बदतर, एक घर, अपने सभी समय को बर्बाद कर रहे थे पेनीज़ (या इससे भी बदतर, काल्पनिक पेनीज़ उनके कंपाइलर या हार्डवेयर की वास्तुकला को समझने में असफल) जब अरबों डॉलर व्यर्थ में कहीं और खर्च किए जा रहे थे।
समय बहुत परिमित है इसलिए उचित प्रासंगिक जानकारी के बिना निरपेक्षता को अनुकूलित करने की कोशिश करना अक्सर हमें उन स्थानों को अनुकूलित करने का अवसर प्रदान करता है जो वास्तव में महत्वपूर्ण हैं, और इस प्रकार, व्यावहारिक प्रभाव के संदर्भ में, मैं कहूंगा कि "समय से पहले अनुकूलन सॉफ्टवेयर को धीमा बनाता है। "
समस्या यह है कि डेवलपर प्रकार हैं जो वस्तुओं के बारे में ऊपर लिखे गए चीज़ों को ले लेंगे और एक कोडिंग मानक स्थापित करने का प्रयास करेंगे जो ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग या उस तरह के कुछ पागल पर प्रतिबंध लगाता है। प्रभावी अनुकूलन प्रभावी प्राथमिकता है, और यदि हम रखरखाव समस्याओं के समुद्र में डूब रहे हैं तो यह बिल्कुल बेकार है।