सी # मेमोरी कैप्चर / फ्री स्पीड

मुझे यह समस्या थी: मुझे डेटा फ़ाइल संसाधित करने की आवश्यकता है। फ़ाइल को लगभग 1 एमबी की लंबाई के साथ अनुभागों में विभाजित किया गया है, उनमें से प्रत्येक में लगभग 100,000 रिकॉर्ड पैक रूप में हैं। रिकॉर्ड की संख्या अनुभाग से अनुभाग तक भिन्न हो सकती है और उनमें से प्रत्येक के शीर्षक में दर्ज की जाती है। प्रसंस्करण के दौरान, अनुभाग अनपैक किया जाता है, और प्रत्येक रिकॉर्ड 20 पूर्णांक में बदल जाता है। प्रसंस्करण के लिए, आपको वर्तमान अनपैक किए गए अनुभाग और कई पिछले वाले (कहीं 5-10 के आसपास, लेकिन शायद अधिक - यह अग्रिम में ज्ञात नहीं है कि कितने) को संग्रहीत करने की आवश्यकता है। सवाल यह है कि अनपैकिंग वर्गों के लिए मेमोरी कैसे आवंटित की जाए।

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

मैंने कुछ वस्तुओं को लिया:

• Ar int int [] [] आकार M * N
• Array int [] लंबाई एन
• एन आइटम लंबे समय की एक घर का बना सूची:
  

  class list{ public list next; public int val; } 

• सूची <int> एन आइटम के साथ

दो-आयामी सरणी के लिए M और N की संख्या का चयन किया गया ताकि M * N = 40,000,000 (जो 20% के लिए एक मेमोरी से मेल खाती है)।
प्रत्येक ऑब्जेक्ट के लिए, बनाने (भरने (पढ़ने के बाद जिस ऑब्जेक्ट को भुला दिया गया था) को मापने के लिए औसत समय, और नियंत्रण के लिए, + पढ़ने (ऑब्जेक्ट को केवल एक बार बनाया गया) भरने का समय निर्धारित किया गया था। समय को वस्तु के संसाधित तत्व के अनुसार नैनोसेकंड में मापा गया था। माप दो बार किया गया था: जब एक प्रोसेसर कोर पर काम कर रहा था और जब समानांतर में 4 कोर पर काम कर रहा था (दूसरे मामले में, 4 पर खर्च किया गया समय गुणा नहीं किया गया था, अर्थात, एक नियम के रूप में, एक ही कोर के मामले में कम होना चाहिए)।

परिणाम इस तरह दिखते हैं:

MXN	8000x5000	2000x20000	1000x40000	100x400000	10x4000000	1x40000000
int [] []	8.34 / 7.30	8.34 / 7.02	4.08 / 2.69 है	3.76 / 2.55	3.62 / 2.58 है	३.६३ / २. 2.78
int [] [], आर + डब्ल्यू	2.57 / 1.60	२.६४ / १.६०	२.२२ / १.०४	2.20 / 1.00	2.18 / 1.00	2.09 / 1.03
int [], पूर्ण	1.94 / 1.04	1.85 / 0.96	३.४ / १.५ 1.5	3.44 / 2.69	3.60 / 3.63	3.60 / 2.78
int [], आर + डब्ल्यू	1.58 / 0.46	1.56 / 0.47	1.56 / 0.47	1.57 / 0.63	1.83 / 0.93	2.00 / 1.05
सूची	16.30 / 9.14	19.16 / 19.00	21.69 / 35.17	53.8 / 85.65	145/130
सूची, पढ़ें	२.३२ / ०.६०	2.29 / 0.61	२.३१ / १.१२	6.4 / 2.58	7.2 / 3.67
सूची <int>	8.95 / 4.21	11.06 / 4.74	11.98 / 5.03	11.85 / 6.38	11.85 / 6.98	13.71 / 8.10
सूची <int>, पढ़ें	2.95 / 0.88	2.96 / 0.92	2.96 / 0.92	2.96 / 0.92	3.13 / 1.05	4.13 / 1.65

प्रत्येक सेल में दो बार रिकॉर्ड किया जाता है - एक और चार कोर के लिए।
इस प्लेट से क्या निकाला जा सकता है? सबसे पहले, यह पता चलता है कि स्मृति को रैखिक रूप से कैप्चर करने में लगने वाला समय सरणी की लंबाई पर निर्भर करता है: 160 एमबी की लंबाई के साथ एक रैखिक सरणी 1.6 एमबी की लंबाई के साथ सरणी की तुलना में 100 गुना लंबे समय तक कैप्चर की जाती है। दूसरे, यदि हम थोड़े समय के लिए एक सरणी पर कब्जा करना चाहते हैं, तो लघु सरणियों का एक फायदा है: उनकी कैप्चर में 0.3 एनएस / शब्द लगता है, जबकि लंबे लोगों का कब्जा 1.8 एनएस / शब्द (3 और 4 लाइनों के बीच का अंतर) है। यह अक्सर उद्धृत दावे की पुष्टि करता है कि 88 केबी से छोटी वस्तुओं को एक अलग, तेज पूल से लिया जाता है। लेकिन अगर बहुत सारे सरणियाँ हैं, तो तस्वीर इसके विपरीत हो जाती है: लंबे सरणियों के लिए लगभग 1.5 ns / शब्द हैं, और छोटे लोगों के लिए - 5.8 ns / शब्द - लगभग 4 गुना अधिक! इसलिए यदि आपको थोड़े समय के लिए बहुआयामी सरणी की आवश्यकता है, तो आपको इसे छोटे आंतरिक सरणियों के साथ कदम से कदम नहीं बनाना चाहिए, दूसरे विकल्प की तलाश करना बेहतर है। उदाहरण के लिए, एक आयामी सरणी को पकड़ो और सूचकांक पढ़ें।

इसके अलावा, यह स्पष्ट है कि प्रणाली को सूची का मेरा कार्यान्वयन बिल्कुल पसंद नहीं आया: जब इसकी लंबाई एक लाख के करीब पहुंच गई, तो एक आइटम बनाने का समय छोटी सूचियों की तुलना में लगभग 6 गुना बढ़ गया।

अपने कार्य के लिए इष्टतम, जाहिरा तौर पर, लंबी सरणियों (एक प्रति-खंड अनुभाग) पर कब्जा करना होगा - अगर मैं किसी भी समय सरणियों पर कब्जा करना चाहता हूं। 1600 वर्गों (यह एक विशिष्ट आकार) की लंबाई वाली फ़ाइल के लिए, समय की हानि 1.5 * 2 * 1.6 = 5 सेकंड होगी। सच है, अब प्रसंस्करण विकल्पों में से एक को पूरा करने में केवल 11 सेकंड लगते हैं (अनावश्यक मेमोरी कैप्चर के बिना), लेकिन सोचने के लिए कुछ है: अन्य प्रसंस्करण लंबे और अधिक जटिल होंगे। यह संभव है कि आपको मेमोरी को फिर से उपयोग करना जारी रखना होगा, न कि गतिशील मेमोरी का दुरुपयोग करना। लेकिन शायद नहीं।