केवल-स्ट्रिंग संग्रह पढ़ें: मैचों पर सहेजें

अक्सर ऐसा होता है कि एक प्रोग्राम कुछ डेटा को मेमोरी में लोड करता है और इसे लंबे समय तक (या यहां तक ​​कि काम के अंत तक) अपरिवर्तित छोड़ देता है। यह डेटा संरचनाओं का उपयोग करता है जो पढ़ने और लिखने दोनों के लिए अनुकूलित हैं। उदाहरण के लिए, आप एनसेंबल डेटाबेस से सभी मानव जीनों के पहचानकर्ताओं की सूची (miRNAs के सभी प्रकारों सहित, आदि, थोड़ा अधिक 50,000) से घटाते हैं। यदि आप उन्हें मानक ArrayList में पढ़ते हैं, तो 32-बिट हॉटस्पॉट पर आप 4 मेगाबाइट से थोड़ा अधिक खर्च करेंगे। क्या मेमोरी को सहेजना संभव है, यह जानते हुए कि संग्रह अब नहीं बदलेगा?

हम डेटाबेस से डेटा को भागों में पढ़ने की क्षमता पर स्पर्श नहीं करेंगे: यह एक और चर्चा का विषय है। इसके अलावा, भागों में पढ़ना यहां वर्णित दृष्टिकोणों के साथ जोड़ा जा सकता है, अतिरिक्त मेमोरी बचत प्राप्त कर सकता है। हम भी उपयोग नहीं करेंगे, उदाहरण के लिए, वर्चुअल मशीन का विकल्प -XX: + UseCompressedStrings: यह न केवल हमारे मामले में स्मृति को बचाता है, बल्कि हमारे तरीकों के साथ भी जोड़ा जा सकता है।

इससे पहले कि आप कुछ का अनुकूलन करें, आपको इसे मापने की आवश्यकता है। हमारे मामले में, हम सूची में व्याप्त स्मृति की मात्रा के बारे में बात कर रहे हैं। और, बेशक, हम उथले आकार (ArrayList वस्तु का आकार) में रुचि नहीं रखते हैं, लेकिन बनाए रखा आकार (ArrayList का आकार और सभी ऑब्जेक्ट जिनमें से यह प्रत्यक्ष या अप्रत्यक्ष रूप से संदर्भित करता है)। हम ग्रहण मेमोरी एनालाइज़र का उपयोग करके मापेंगे। हीप पर वांछित वस्तु का पता लगाएं (उदाहरण के लिए, वर्ग नाम से) और शो बरकरार सेट विकल्प का उपयोग करें। हमें निम्न चित्र मिलते हैं:



उम्मीद के मुताबिक, ArrayList का वज़न बहुत कम है - 24 बाइट्स। ऑब्जेक्ट की सरणी [] स्ट्रिंग संदर्भों को ArrayList के अंदर निर्णायक रूप से तौला जाता है, लेकिन अभी भी अंतरिक्ष के 90% से अधिक स्ट्रिंग ऑब्जेक्ट्स और उनके साथ जुड़े [[] सरणियों द्वारा खपत होती है।

तत्वों की वास्तविक संख्या के लिए ऑब्जेक्ट [] सरणी को ट्रिम करके एक मामूली सुधार प्राप्त किया जा सकता है। जैसा कि आप जानते हैं, ArrayList एक मार्जिन के साथ अंतरिक्ष आवंटित करता है ताकि हर बार एक तत्व को फिर से आवंटित न किया जाए। चूंकि हम जानते हैं कि कोई और तत्व नहीं जोड़ा जाएगा, इसलिए हमें इस स्टॉक की आवश्यकता नहीं है। यह निम्नानुसार और प्रभावी ढंग से किया जा सकता है:

List<String> genes = readGenes(); genes = Arrays.asList(genes.toArray(new String[genes.size()])); 

यहाँ परिणाम अब एक ArrayList (अधिक सटीक, एक ArrayList, लेकिन दूसरा) नहीं है। हम पहले वांछित लंबाई के सरणी की एक प्रति बनाते हैं, और फिर इसे कॉपी पर लपेटते हैं। अब बरकरार सेट इस तरह दिखता है:



सरणी थोड़ी छोटी हो गई है, लेकिन अंत में हमने 0.44% स्थान बचा लिया। खैर, कुछ भी नहीं, हम बस गर्म करते हैं।

आइए इन चार को देखें [] सरणियाँ। उनमें "ENSG00000121410" (15 अक्षर - 30 बाइट्स) प्रकार के जीन पहचानकर्ता होते हैं, जो ऑब्जेक्ट के बारे में सिस्टम की एक और 8 बाइट्स और लंबाई के 4 बाइट्स हैं। और इन 42 बाइट्स को 8 में संरेखित किया गया है, अर्थात 6 अप्रयुक्त बाइट्स अभी भी जोड़े गए हैं। इस प्रकार, 48 बाइट्स में से, केवल 30 उपयोगी जानकारी लेती हैं (+ UseCompressedStrings के साथ उन्हें 15 तक कम किया जा सकता है, फिर "अतिरिक्त" जानकारी का अनुपात और बढ़ जाएगा)। इससे क्या हो सकता है?

याद रखें कि String.substring कैसे काम करता है। परिणामी लाइन जो बफ़र चार्ट [] को पैरेंट लाइन के साथ साझा करती है: ऑफसेट और काउंट को चाइल्ड लाइन के अनुसार सेट किया जाता है। इस मामले में, उपयोगकर्ता के दृष्टिकोण से चाइल्ड लाइन सामान्य से अलग नहीं है, लेकिन यदि पेरेंट लाइन को हटा दिया गया था, तो पूर्ण बफर अभी भी संग्रहीत है, भले ही आप मेगाबाइट लाइन से एक वर्ण काट लें। कभी-कभी यह कष्टप्रद होता है, आपको कोड में ऐसी जगहों की तलाश करनी होगी और एक नए स्ट्रिंग पर हस्ताक्षर करना होगा, लेकिन अब, इसके विपरीत, यह हमारी मदद करेगा। हम सरणी के सभी लाइनों को एक चार [] बफर पर डाल देंगे। ऐसा करने के लिए, हम कुछ उपयोगिता वर्ग में एक सहायक विधि लिखते हैं:

 public static List<String> compactify(Collection<String> list) { StringBuilder sb = new StringBuilder(); for( String item : list ) sb.append(item); String data = sb.toString(); List<String> result = new ArrayList<String>(list.size()); int index = 0; for( String item : list ) { result.add(data.substring(index, index + item.length())); index += item.length(); } return result; } 

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



हाँ, पहले से ही महत्वपूर्ण है। हमने ऊपर बताए गए लगभग सभी अतिरिक्त बाइट्स को बचा लिया, कुल मिलाकर मूल आकार के 24% जीतने में। यदि आपकी सरणी में रेखाएं 15 वर्णों से छोटी हैं, तो बचत और भी अधिक होगी। ध्यान दें, जिस तरह से एक ArrayList बनाते समय हमने स्पष्ट रूप से इसकी लंबाई निर्दिष्ट की है, इसलिए ऑब्जेक्ट [] में अतिरिक्त तत्व नहीं हैं, अर्थात, हमने पहला अनुकूलन नहीं खोया।

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

फिर भी 24% कुछ कम हैं। स्ट्रिंग ऑब्जेक्ट्स जो अनिवार्य रूप से अच्छा नहीं करते हैं (डेटा [char] में ही) आंख को काटते हैं। शायद आप उन्हें स्टोर नहीं कर सकते, लेकिन मांग पर स्ट्रिंग काट लें? ऐसा करने के लिए, हमें सूची के हमारे कार्यान्वयन को लिखना होगा और लाइनों की शुरुआत के ऑफसेट स्टोर करना होगा:

 public class CompactStringList extends AbstractList<String> implements RandomAccess { private String data; private int[] offsets; public CompactStringList(Collection<String> list) { StringBuilder sb = new StringBuilder(); offsets = new int[list.size()]; int offset = 0, i = 0; for( String item : list ) { sb.append(item); offsets[i++] = offset; offset+=item.length(); } data = sb.toString(); } public String get(int index) { return index == offsets.length - 1 ? data.substring(offsets[index]) : data.substring(offsets[index], offsets[index + 1]); } public int size() { return offsets.length; } } 

कंस्ट्रक्टर में, हमने फिर से सभी इनपुट लाइनों को एक में विभाजित किया, एक पंक्ति में लाइनों की शुरुआत के ऑफसेट को याद करते हुए। तत्व की प्राप्ति पर (सादगी के लिए, मैं पैरामीटर की शुद्धता की जांच नहीं करता हूं), हम स्ट्रिंग से वांछित टुकड़ा काटते हैं। इस स्थिति में, केवल एक नया स्ट्रिंग ऑब्जेक्ट बनाया जाता है, और डेटा स्वयं कॉपी नहीं किया जाता है। ऐसी किसी वस्तु के बनाए हुए सेट पर एक नज़र डालें:



अब हमने मूल संस्करण की तुलना में 55.5% बचाया है, यहां आप पहले से ही नृत्य कर सकते हैं।

बेशक, नवीनतम अनुकूलन सबसे विवादास्पद है और आगे उपयोग के मामलों पर निर्भर करता है। उदाहरण के लिए, यदि आप अक्सर एक ही तत्व प्राप्त करते हैं और परिणामी तार को अन्य संग्रह में सहेजते हैं, तो आपके स्ट्रिंग ऑब्जेक्ट्स गुणा करेंगे। यद्यपि वे एक सामान्य बफर की ओर इशारा करते हैं, आप प्रति पंक्ति 40 बाइट्स (32-बिट हॉटस्पॉट में) खो देंगे। अनुकूलन के लिए अनुकूलन के साथ दूर मत जाओ: यह केवल बदतर हो सकता है। हालाँकि, कई अनुप्रयोगों में यह विधि उपयोगी हो सकती है। खैर, या अंतिम उपाय के रूप में, यह कुछ पाठकों के लिए जावा सुविधाओं की समझ का विस्तार करेगा।