क्या आपको बहुत सी छोटी वस्तुओं के निर्माण को कम करना चाहिए?

Question

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

मेरे पास एक उदाहरण है जो इस विचार को अच्छी तरह दिखाता है। एक ग्राफिक्स प्रोग्राम में, कहते हैं कि एक विधि है जो सभी ड्राइंग के लिए उपयोग की जाती है जिसे आदर्श रूप से कहा जाता है drawPixel(Point)। बनाए जा सकने वाले पॉइंट्स की अधिकता हो सकती है और इसे अक्सर दोहराया जा सकता है, जैसे एक गेम में जहाँ इसे 60+ बार सेकंड कहा जा सकता है। वैकल्पिक रूप से, drawPixel(int x, int y)कई बिंदु वस्तुओं के निर्माण को कम करने के लिए इस्तेमाल किया जा सकता है।

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

Comments

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

@Snowman मैंने सुना है कि जावा के नए संस्करण मेमोरी प्रबंधन के साथ बेहतर करते हैं, लेकिन मुझे जो समस्या है वह यह है कि कोई गारंटी नहीं है कि उपयोगकर्ता पुराने संस्करण का उपयोग नहीं कर रहा है। यह मेरी इस चिंता का हिस्सा है।

— स्ट्रिपीज़

पहले कुछ प्रदर्शन माप करें। यदि आपको कुछ परेशानी है, तो सोचें कि अनुकूलन कैसे करें। लेकिन कृपया कोड के रख-रखाव को जल्दी से जल्दी न करें क्योंकि आपको लगता है कि आपको कुछ प्रदर्शन परेशानियाँ हो सकती हैं।

— स्पॉट किया गया

@स्ट्रिपी पहले से ही मौजूद जावा ऑब्जेक्ट्स का प्रदर्शन, जिनका उत्तर हमें जावा में ऑब्जेक्ट निर्माण से बचना चाहिए? । हालाँकि यदि आपको कभी भी प्रति सेकंड करोड़ों ऐसी वस्तुओं को संभालना है तो केवल उस बिंदु पर इस मुद्दे पर पुनर्विचार करें।

— रवांग

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

— जेरी कॉफिन

Answer 1

सामान्य तौर पर, नहीं , आपको प्रदर्शन हानि के डर से ऑब्जेक्ट बनाने से बचना चाहिए। इसके अनेक कारण हैं।

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

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

यदि यह मामला है, तो सुनिश्चित करें, intएक वस्तु में लपेटने के बजाय दो एस पास करें और आगे बढ़ें । OOP की बात यह नहीं है कि सब कुछ एक वस्तु होना चाहिए। मुद्दा यह है कि ऑब्जेक्ट उन स्थानों पर विकास को आसान बनाते हैं जहां वे डेटा प्रतिनिधित्व समस्या का प्राकृतिक समाधान हैं। उन वस्तुओं से बचें, जहाँ वे समझ में नहीं आते हैं - जहाँ वे नहीं करते हैं, उनसे परिचय न करें।

Answer 2

जब आप कोड लिखे जाने से पहले प्रदर्शन पर प्रभाव पर विचार करते हैं, तो आपको यह मान लेना चाहिए कि आप नहीं जानते कि आप क्या कर रहे हैं।

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

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

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

Answer 3

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

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

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

OOP कुछ कारणों से एक अच्छा विचार है। वे कारण सभी स्थितियों में लागू नहीं होते हैं ।

Comments

मैं सहमत हूं, लेकिन मैं हर किसी के साथ सहमत हूं कि परीक्षण सुनिश्चित करने का एकमात्र तरीका है। सुनिश्चित करें कि आपके पास इसे अनुकूलित करने से पहले इसे सरल / स्पष्ट तरीके से करने का चश्मा है ... लेकिन मैं मानता हूं कि नया अभी भी एक मुद्दा हो सकता है।

— बिल के

Answer 4

आगे बढ़ें और छोटे आवंटन का उपयोग करें। आधुनिक मेमोरी मैनेजर, विशेष रूप से अत्यधिक अनुकूलित जावा ऑब्जेक्ट मैनेजर, बेहद कुशल हैं। एक कार्यशील कार्यक्रम के लिए प्रमुख प्रदर्शन अनुकूलन को सहेजें।

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

मैंने एक बार एक टीम मेंबर को कई दिन बिताए थे जिससे ऑब्जेक्ट मेंबर लुक 20x तेजी से बना। सफलता! हालांकि, वास्तविक उपयोग में सबसे अच्छा समग्र गति प्रतिशत के सौवें हिस्से में मापा गया था। परिवर्तन को तुरंत वापस कर दिया गया था, क्योंकि स्पीडअप को प्रति सदस्य मेमोरी आवंटन में बड़ी आवश्यकता थी।

Answer 5

यह सरल है: यदि आपको 1000 छोटी वस्तुओं की आवश्यकता है, तो आप 1000 छोटी वस्तुओं का निर्माण करते हैं और इसके बारे में चिंता नहीं करते हैं। यदि आपको 100 छोटी वस्तुओं की आवश्यकता है , तो 1000 छोटी वस्तुओं का निर्माण करना बेवकूफी है - उन चीजों को बनाएं जिनकी आपको आवश्यकता है और अधिक नहीं।

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