स्काला (या जावा) में अनुकूली मैप्स प्रविष्टि आदेश

संरक्षण मैं खोजने के लिए और पुन: उपयोग (यदि संभव हो तो) एक नक्शे के कार्यान्वयन जो निम्नलिखित गुण होते हैं चाहते हैं:स्काला (या जावा) में अनुकूली मैप्स प्रविष्टि आदेश

प्रविष्टियों की संख्या कम है, वहीं कहना < 32, अंतर्निहित भंडारण इस तरह की सरणी में किया जाना चाहिए [key0, val0, key1, val1, ...] यह स्टोरेज योजना कई छोटी प्रविष्टि ऑब्जेक्ट्स से बचाती है और अत्यधिक तेज दिखने के लिए प्रदान करती है (यहां तक कि वे अनुक्रमिक स्कैन भी हैं!) सीपीयू के कैश के कारण आधुनिक सीपीयू पर अमान्य नहीं किया जा रहा है और ढेर में सूचक संकेत की कमी है।
नक्शा कुंजी/मान जोड़े के लिए प्रविष्टि आदेश में समान प्रविष्टियों की संख्या की परवाह किए बिना बनाए रखना चाहिए LinkedHashMap को

हम विशाल (नोड/किनारों के लाखों लोगों) का इन-स्मृति अभ्यावेदन पर काम कर रहे स्कैला में ग्राफ और इस तरह के एक मानचित्र होने से हमें नोड/एज गुणों के साथ-साथ एज प्रति नोड को 99% + नोड्स और एज के लिए एक अधिक कुशल तरीके से स्टोर करने की अनुमति मिल जाएगी, जिसमें दोनों गुणों या पड़ोसियों के लिए क्रोनोलॉजिकल सम्मिलन आदेश को संरक्षित करते समय गुण और किनारों।

यदि किसी को ऐसी विशेषताओं के साथ स्कैला या जावा मानचित्र के बारे में पता है तो मैं बहुत अधिक बाध्य होगा।

Thanx

स्रोत

2010-09-02 Alex Kravets

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

चूंकि आप पहले ही कार्यान्वयन के बारे में सोच रहे हैं, आप अपना खुद का लेखन क्यों नहीं करते? एक सरणी या एक LinkedHashMap के चारों ओर एक रैपर लिखना मुश्किल नहीं हो सकता है। – starblue

आप एक विशेष मामले के लिए अपने संग्रह का उपयोग कर रहे हैं। इसलिए आपको बचत के इस तरह के सामान्य तरीके से परेशान नहीं होना चाहिए। उच्च प्रदर्शन प्राप्त करने के लिए, अपना खुद का डेटास्ट्रक्चर बनाना दिलचस्प होगा। आप अपने मामले के लिए अपने strukture अनुकूलित कर सकते हैं, क्योंकि ऐसा लगता है कि आप अपने ग्राफ का बहुत अधिक जानते हैं। इसलिए आपको पेड़ों, सूचियों, जो भी हो, इसके बारे में उच्चतम संभावित प्रदर्शन प्राप्त करने के बारे में सोचना चाहिए। हो सकता है कि आपको O (n * logn) या उससे कम का रनटाइन प्रदर्शन प्राप्त हो ....;) –

जावा के तहत आप एक 2d सरणी (स्प्रेडशीट) बनाए रख सकते हैं। मैंने एक कार्यक्रम लिखा जो डेटा को देखने के लिए मूल रूप से डेटा के 3 कॉलमन्स के साथ 2 डी सरणी और 3 कॉलमन्स परिभाषित करता है। तीन coloumns testID, SubtestID और मोड हैं। यह मुझे मूल रूप से टेस्टिड और मोड या किसी भी संयोजन द्वारा एक मान को देखने की अनुमति देता है, या मैं स्थैतिक प्लेसमेंट द्वारा भी संदर्भित कर सकता हूं। तालिका को स्टार्टअप पर स्मृति में लोड किया गया है और प्रोग्राम द्वारा संदर्भित किया गया है। यह बेहद विस्तार योग्य है और आवश्यकतानुसार नए मूल्य जोड़े जा सकते हैं।

यदि आप रुचि रखते हैं, तो मैं आज रात कोड स्रोत उदाहरण पोस्ट कर सकता हूं।

एक और विचार आपके कार्यक्रम में डेटाबेस बनाए रखने के लिए हो सकता है। डेटाबेस को बड़ी मात्रा में डेटा व्यवस्थित करने के लिए डिज़ाइन किया गया है।

स्रोत

2010-10-06 18:59:58

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

जबकि मुझे आपकी आवश्यकताओं के अनुरूप बिल्कुल लागू होने वाले किसी भी कार्यान्वयन से अवगत नहीं है, तो आप जकार्ता कॉमन्स लाइब्रेरी में Flat3Map (source) पर देखकर रुचि ले सकते हैं।

दुर्भाग्य से, जकार्ता पुस्तकालयों को पुराना है (उदाहरण के लिए, नवीनतम स्थिर रिलीज में जेनेरिक के लिए कोई समर्थन नहीं है, हालांकि यह देखने का वादा है कि यह ट्रंक में बदल रहा है) और मैं आमतौर पर Google Collections पसंद करता हूं, लेकिन यह लायक हो सकता है आपका समय यह देखने के लिए कि अपाचे ने चीजों को कैसे लागू किया।

Flat3Map चाबियों के क्रम को सुरक्षित नहीं करता है, दुर्भाग्यवश, लेकिन मेरे पास आपकी मूल पोस्ट के संबंध में कोई सुझाव है। [key0, val0, key1, val1, ...] जैसे एकल सरणी में कुंजियों और मानों को संग्रहीत करने के बजाय, मैं समांतर सरणी का उपयोग करने की सलाह देता हूं; वह है, [key0, key1, ...] के साथ एक सरणी और दूसरा [val0, val1, ...] के साथ। आम तौर पर मैं समानांतर सरणी का समर्थक नहीं हूं, लेकिन कम से कम इस तरह से आप एक प्रकार का प्रकार, आपके कुंजी प्रकार, और अन्य प्रकार के वी, आपके मान प्रकार का एक प्रकार प्राप्त कर सकते हैं। जावा स्तर पर, इसका अपना वार सेट है क्योंकि आप सिंटैक्स K[] keys = new K[32] का उपयोग नहीं कर सकते हैं; इसके बजाय आपको a bit of typecasting का उपयोग करने की आवश्यकता होगी।

स्रोत

2010-10-10 06:14:26 ide

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

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

स्रोत

2010-10-12 10:26:22 iirekm

समस्या गति या न केवल गति की गति है, यह भी आवंटित, बनाए रखा और जीसी'ड की छोटी Emtry वस्तुओं की संख्या है। –

लेकिन आवंटन समय धीमा हो जाता है - जितना अधिक ऑब्जेक्ट आप धीमे प्रोग्राम आवंटित करते हैं, इसलिए यह सभी प्रोफाइलर द्वारा निष्पादित प्रदर्शन को कम कर देता है। – iirekm

आज जहां अधिकांश कंप्यूटरों में 4 जीबी मेमोरी मेमोरी यूज ऑप्टिमाइज़ेशन हैं, शायद ही कभी समझ में आता है। हालांकि, जब आमतौर पर फ्लाईवेट पैटर्न का उपयोग करना सबसे अच्छा होता है। जावा स्विंग से ट्रीमोडेल में एक उदाहरण पाया जा सकता है। node.getAttribute (key) = node.attributeMap.get (key) के बजाय node.getAttribute (key) = graph.attributeModel.getAttribute (node) – iirekm

स्काला (या जावा) में अनुकूली मैप्स प्रविष्टि आदेश

उत्तर

संबंधित मुद्दे