मल्टीमैप अंतरिक्ष मुद्दा: अमरूद

Question

मेरी जावा कोड, मैं अमरूद के मल्टीमैप (com.google.common.collect.Multimap) का उपयोग कर रहा में इस का उपयोग करते हुए:

Multimap<Integer, Integer> Index = HashMultimap.create() 

यहाँ, मल्टीमैप कुंजी एक यूआरएल के कुछ हिस्से और मूल्य यूआरएल के एक अन्य भाग है (एक पूर्णांक में परिवर्तित)। अब, मैं अपना जेवीएम 2560 एमबी (2.5 जीबी) हीप स्पेस (एक्सएमएक्स और एक्सएमएस का उपयोग करके) असाइन करता हूं। हालांकि, यह केवल पूर्णांक के 9 लाख (कुंजी, मूल्य) जोड़े (लगभग 10 मिलियन) स्टोर कर सकता है। लेकिन, सैद्धांतिक रूप से (स्मृति के अनुसार int पर कब्जा कर लिया गया) इसे और अधिक स्टोर करना चाहिए।

किसी को भी मेरी मदद कर सकते,

1. क्यों Multimap स्मृति के बहुत सारे उपयोग कर रहा है? मैंने अपना कोड चेक किया और जोड़े को Multimap में डाले बिना, यह केवल 1/2 एमबी मेमोरी का उपयोग करता है।
2.

वहाँ एक और तरीका है या घर में पके हुए समाधान इस स्मृति मुद्दे को हल करने के लिए है? मतलब, क्या उन ऑब्जेक्ट ओवरहेड्स को कम करने का कोई तरीका है क्योंकि मैं केवल इंट-इंट स्टोर करना चाहता हूं? किसी अन्य भाषा में? या किसी भी अन्य समाधान (घर-बेक्ड पसंदीदा) को हल करने के लिए मुझे सामना करने के लिए, डीबी आधारित या उस समाधान की तरह कुछ मतलब है।

Answer 1

Multimap से जुड़ी भारी मात्रा में ओवरहेड है। कम से कम:

• प्रत्येक कुंजी और मान एक Integer वस्तु है, जो (कम से कम) प्रत्येक int मूल्य का भंडारण आवश्यकताओं दोगुना हो जाता है है।
• HashMultimap में प्रत्येक अद्वितीय कुंजी मान मूल्यों की एक Collection साथ जुड़ा हुआ है (the source के अनुसार, Collection एक Hashset है)।
• प्रत्येक Hashset 8 मानों के लिए डिफ़ॉल्ट स्थान के साथ बनाया गया है।

इसलिए प्रत्येक कुंजी/मूल्य जोड़ी की आवश्यकता होती है (कम से कम) शायदमानों के मुकाबले अधिक जगह की परिमाण की आवश्यकता हो सकती है। (कुछ हद तक कम जब एक ही कुंजी के तहत एकाधिक मान संग्रहीत किए जाते हैं।) मैं उम्मीद करता हूं कि 10 मिलियन कुंजी/मूल्य जोड़े शायद 400 एमबी लेंगे।

हालांकि आपके पास 2.5 जीबी ढेर की जगह है, लेकिन यह सब आश्चर्यचकित नहीं होगा अगर यह पर्याप्त नहीं है। उपरोक्त अनुमान, मुझे लगता है, कम तरफ। इसके अलावा, यह केवल खाते के निर्माण के बाद मानचित्र को स्टोर करने के लिए कितना आवश्यक है। जैसे-जैसे नक्शा बढ़ता है, तालिका को फिर से आवंटित करने और पुनर्स्थापित करने की आवश्यकता होती है, जो अस्थायी रूप से कम से कम स्थान की मात्रा को दोगुना कर देता है। अंत में, यह सब मानता है कि int मान और ऑब्जेक्ट संदर्भों को 4 बाइट की आवश्यकता होती है। यदि JVM 64-बिट एड्रेसिंग का उपयोग कर रहा है, तो बाइट गिनती शायद दोगुनी हो सकती है।

Answer 2

ऐसा लगता है कि आपको एक स्पैस बूलियन मैट्रिक्स की आवश्यकता है। Sparse matrices/arrays in Java लाइब्रेरी कोड को पॉइंटर्स प्रदान करना चाहिए। फिर मल्टीमैप में (i, j) डालने के बजाय, बस [1] [j] पर मैट्रिक्स में 1 डाल दें।

Answer 3

शायद

स्मृति भूमि के ऊपर कम करने के लिए संभावित Trove's आदिम संग्रह कार्यान्वयन (मुक्केबाजी के स्मृति भूमि के ऊपर से बचने के लिए) मिश्रण और

SetMultimap<Integer, Integer> multimap = Multimaps.newSetMultimap(
    TDecorators.wrap(TIntObjectHashMap<Collection<Integer>>()), 
    new Supplier<Set<Integer>>() { 
    public Set<Integer> get() { 
     return TDecorators.wrap(new TIntHashSet()); 
    } 
    }); 

अभी भी मुक्केबाजी के उपरि है यही कारण है कि जैसे अमरूद के Multimap, कुछ करने के लिए किया जाएगा सबसे आसान तरीका और प्रश्नों पर अनबॉक्सिंग, लेकिन वहां बस बैठे मेमोरी में काफी कमी आएगी।

Answer 4

आप शायद एक ऐरेलिस्टमल्टीमैप का उपयोग कर सकते हैं, जिसके लिए हैशमल्टीमैप की तुलना में कम स्मृति की आवश्यकता होती है, क्योंकि ऐरेलिस्ट्स हैशसेट्स से छोटे होते हैं। या, आप स्मृति उपयोग को कम करने के लिए, सूची के साथ सेट को प्रतिस्थापित करने, लुइस के ट्रोव समाधान को संशोधित कर सकते हैं।

कुछ एप्लिकेशन इस तथ्य पर निर्भर करते हैं कि हैशमल्टीमैप SetMultimap इंटरफ़ेस को संतुष्ट करता है, लेकिन अधिकांश नहीं।