जब स्मृति पदचिह्न की बात आती है तो क्लोजर कितनी अच्छी तरह से प्रदर्शन करता है?

Question

पृष्ठभूमि के लिए, मैं क्लोजर में एक वेब सेवा लिख ​​रहा हूं (इस मामले में कंपोजर I का उपयोग करके)। मैं प्रदर्शन के बारे में चिंतित नहीं हूं, ऐसा लगता है कि यह काफी अच्छा है और मैं हमेशा अधिक सर्वर उदाहरणों को ऊपर उठा सकता हूं।

भले ही क्लोजर कार्यान्वयन इसी जावा कार्यान्वयन से 2-10 गुना धीमा हो, फिर भी मैं कच्चे प्रदर्शन से पहले क्लीनर कोड पसंद करूंगा।

बेशक, यह आपके द्वारा किए जा रहे कार्यों पर निर्भर करता है, लेकिन जावा जानकार क्लोजर में किसी भी प्रकार के लंबे समय से चलने वाले सर्वर समाधानों की मेमोरी पदचिह्न की बात आती है, तो मैं जानना चाहूंगा कि आपके पास वास्तविक वास्तविक अनुभव हैं या नहीं?

Answer 1

मेरे पास एक सक्रिय कंपोज़र आधारित वेब सर्वर है जो बिना किसी हिच के चार महीने से अधिक समय तक चल रहा है (यानी कोई आउटऑफमेमरी एक्सेप्शन या ऐसा कुछ भी नहीं ....)। तो क्लोजर लंबे समय तक चलने वाले सर्वर अनुप्रयोगों में बहुत मजबूत लगता है।

वेब सर्वर लगभग अमेज़ॅन ईसी 2 पर चल रहा है। 230 एमबी मेमोरी पदचिह्न।

यह सच है कि क्लोजर अपेक्षाकृत स्मृति भूख लगी है - सामान्य जेवीएम ओवरहेड के अतिरिक्त यह स्मृति में खाने वाली पृष्ठभूमि में गतिशील वर्ग पीढ़ी जैसी कई चीजें करता है। यह बहुत सारी अस्थायी वस्तुओं (जैसे अनुक्रम वस्तुओं का निर्माण) उत्पन्न करता है और चीजों को साफ़ करने के लिए जीसी पर निर्भर करता है।

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

Answer 2

एक और समस्या JVM में एक साधारण डिज़ाइन दोष है: यह यूटीएफ -16 को अपने आंतरिक स्ट्रिंग एन्कोडिंग के रूप में उपयोग करता है, इसलिए एक अमेरिकी केंद्रित डेटा सेट में सभी तारों को जितनी मेमोरी चाहिए उतनी बार लेनी चाहिए।