क्या मुक्केबाजी .NET में कचरा बनाती है?

Question

मैं सोच रहा हूं कि मुक्केबाजी एक वस्तु में एक मूल्य प्रकार एक विशेष मामला है या क्या .NET द्वारा निर्मित "बॉक्स" कचरा बन जाता है (जिसे जीसी एकत्र करना है) इसके किसी भी संदर्भ के बाद गिरा दिया जाता है। ,

StringBuilder.AppendFormat(string format, object arg0); 
StringBuilder.AppendFormat(string format, object arg0, object arg1); 
StringBuilder.AppendFormat(string format, object arg0, object arg1, object arg2); 
StringBuilder.AppendFormat(string format, params object[] args); 

3 या इससे कम तर्क के साथ कॉल के लिए उन अतिरिक्त भार के होने कि मुक्केबाजी संकेत हो सकता है वास्तव में एक विशेष मामला है (या इसे बंद का भुगतान करती है कि

:

उदाहरण के लिए, StringBuilder.AppendFormat() इन भार के है सरणी निर्माण से बचने के लिए, प्रदर्शन बिंदु-दृश्य से)।

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

Answer 1

सबसे पहले, स्पष्ट करने के लिए: ऑब्जेक्ट संदर्भों की एक सरणी बनाना मुक्केबाजी नहीं है। "बॉक्सिंग" एक शब्द है जो .NET में एक बहुत ही विशिष्ट अर्थ के साथ है, और मुझे लगता है कि यह चिपकने लायक है।

बॉक्सिंग कचरा बनाते हैं - या बल्कि, जब भी आप बॉक्स करते हैं, यह एक नई वस्तु बनाता है जो अंततः कचरा बनने की संभावना है। (यह नहीं कचरा बनने के लिए है करता है - तो आप ऐप के जीवन के आराम के लिए उस वस्तु के लिए एक संदर्भ हो सकता है, यह सिर्फ सुंदर दुर्लभ है।)

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

Integer x = 5; 
Integer y = 5; 
System.out.println(x == y); // Reference comparison 

तो उस true मुद्रित करने के लिए गारंटी है।

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

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

शायद यह ध्यान देने योग्य है कि .NET 2.0 के बाद, मुक्केबाजी कुछ हद तक दुर्लभ है। यह डेटा बाध्यकारी और प्रतिबिंब में एक उचित राशि होती है, लेकिन अब पुराने पुराने डेटा मैनिपुलेशन में यह कम आम है।

Answer 2

बॉक्सिंग वाला एक वैल्यू टाइप ढेर पर एक ऑब्जेक्ट बन जाता है, और किसी अन्य ऑब्जेक्ट की तरह (और इच्छा) कचरा हो जाना चाहिए जब इसे अब संदर्भित नहीं किया जाता है।

सरणी निर्माण से बचने के लिए 3 या कम तर्कों के साथ विधि ओवरलोड बनाना (जैसा कि आप देखते हैं), और एक प्रदर्शन अनुकूलन है। Members with a Variable Number of Parameters पर "बेहद प्रदर्शन-संवेदनशील एपीआई में छोटी संख्या में तर्कों के साथ कॉल के लिए विशेष अधिभार और कोड पथ प्रदान करने पर विचार करें" देखें।

हालांकि, एक सरणी बनाना मूल रूप से मुक्केबाजी के मुकाबले एक मूल्य प्रकार से अलग है। StringBuilder.AppendFormat के किसी भी ओवरलोड को कॉल करना हमेशा तर्क प्रकारों के बॉक्स तर्क होगा, क्योंकि पैरामीटर object के रूप में टाइप किया गया है, चाहे कोई सरणी बनाई गई हो या नहीं। मुक्केबाजी के विस्तृत स्पष्टीकरण के लिए, .NET: Type Fundamentals पर "बॉक्सिंग और अनबॉक्सिंग" देखें।

Answer 3

आप गलत सवाल पूछ रहे हैं।

आप जिस ओवरलोड को इंगित कर रहे हैं वह सीधे पैरामीटर कॉलिंग के लिए अनुकूलित करना है। मतलब कंपाइलर var_0 को arg_0, arg_1, arg_2, arg_3 में डाल देगा, यह उससे अधिक होना संभव है, लेकिन आईएल में केवल इन्हें त्वरित पहुंच है। शेष वैसे भी ढेर के माध्यम से चला जाता है, और इसलिए परम टाइप किए गए फ़ंक्शन कॉल की तुलना में अधिक प्रभावशाली नहीं है।

परम टाइप किए गए फ़ंक्शन कॉल के लिए, यह वास्तव में दृश्यों के पीछे एक सरणी बनाता है और इसे फ़ंक्शन में arg_1 के रूप में भेजता है (इस मामले में, जहां arg_0 स्ट्रिंग द्वारा लिया जाता है)।