संसाधन उपयोग को अनुकूलित करने के लिए चर का पुन: उपयोग किया जाना चाहिए?

Question

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

Bitmap workPic, editPic; 
... 
void Method1() { 
    workPic = new Bitmap(editPic); 
    ... 
} 
void Method2() { 
    workPic = new Bitmap(editPic.Width * 2, editPic.Height * 2); 
    ... 
} 

या प्रत्येक विधि में एक स्थानीय चर घोषित:

Bitmap editPic; 
... 
void Method1() { 
    Bitmap workPic = new Bitmap(editPic); 
    ... 
} 
void Method2() { 
    Bitmap workPic = new Bitmap(editPic.Width * 2, editPic.Height * 2); 
    ... 
} 

दूसरा तरीका कोड स्पष्टता (स्थानीय उपयोग के लिए स्थानीय चर) के लिए बेहतर है। संसाधन उपयोग के मामले में कोई अंतर है?

Answer 1

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

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

नोट DisposeworkPic के लिए यह बहुत महत्वपूर्ण है क्योंकि अब आपके पास Bitmap के पीछे अप्रबंधित स्मृति में मेमोरी लीक है। पसंदीदा रूप से using का उपयोग करें।

Answer 2

क्यों वैश्विक चर बचा जाना चाहिए जब अनावश्यक

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

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

अंतर्निहित युग्मन - कई वैश्विक चर के साथ एक कार्यक्रम अक्सर चर और कार्यों के बीच उन चर के कुछ है, और कपलिंग्स के बीच तंग कपलिंग्स है। युग्मित वस्तुओं को समेकित इकाइयों में समूहित करना आमतौर पर बेहतर कार्यक्रमों की ओर जाता है।

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

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

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

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

संदर्भ: http://c2.com/cgi/wiki?GlobalVariablesAreBad

Answer 3

यहाँ समझने के लिए मुख्य बात यह है कि क्षेत्र है और चर केवल एक संदर्भ रखा है, स्मृति वस्तु (रों) 'नई' के द्वारा बनाई गई करने के लिए आवंटित किया जाएगा। तो दोनों मामलों में सभी निर्मित बिटमैप ऑब्जेक्ट्स को कचरा संग्रह से गुज़रना पड़ता है।

अंतर यह है कि विधि में संदर्भित ऑब्जेक्ट विधि निष्पादन के ठीक बाद एकत्रित करने के लिए तैयार होगा, जब ऑब्जेक्ट जो अभी भी किसी फ़ील्ड में संदर्भित है, तब भी एकत्रित होने के लिए तैयार होगा जब फ़ील्ड युक्त ऑब्जेक्ट भी तैयार होगा इकट्ठा करने का है।

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

मामलों में जब आप विधि की शुरुआत में ऑब्जेक्ट को फिर से बनाते हैं तो निश्चित रूप से चर की अनुशंसा की जाती है।