2010-07-08 25 views
7

मेरे पास बड़ी संख्या में (> 100k) अपेक्षाकृत छोटी फ़ाइलें (1kb - 300kb) हैं जिन्हें मुझे पढ़ने और संसाधित करने की आवश्यकता है। मैं वर्तमान में सामग्री को पढ़ने, इसे संसाधित करने और फिर अगली फ़ाइल पढ़ने के लिए सभी फ़ाइलों के माध्यम से लूपिंग कर रहा हूं और File.ReadAllText का उपयोग कर रहा हूं। यह काफी धीमा है और मैं सोच रहा था कि इसे अनुकूलित करने का कोई अच्छा तरीका है या नहीं।बड़ी संख्या में फ़ाइलों को पढ़ना

मैंने पहले से ही कई धागे का उपयोग करने का प्रयास किया है, लेकिन ऐसा लगता है कि आईओ बाध्य है, मुझे कोई सुधार नहीं दिख रहा है।

+0

कौन सा हिस्सा सबसे लंबा समय ले रहा है? फ़ाइलों को लोड करना या उन्हें संसाधित करना? –

+0

@ निकलर्सन: फाइल लोड हो रहा है। – Tim

+0

भले ही उन्हें लोड करना सबसे लंबा हो, मल्टीथ्रेडिंग आपको अभी भी लाभ प्रदान कर सकती है, क्योंकि यह कम से कम रनटाइम से प्रोसेसिंग पहलू को कम से कम हटा सकता है। –

उत्तर

7

आप सबसे अधिक संभावना सही हैं - पढ़ना कि कई फाइलें शायद आपकी संभावित गति को सीमित करने जा रही हैं क्योंकि डिस्क I/O सीमित कारक होगा।

कहा जा रहा है कि, आप डेटा की प्रसंस्करण को एक अलग थ्रेड में पास करके थोड़ा सा सुधार कर सकते हैं।

मैं आपकी फाइलों को पढ़ने वाले एकल "निर्माता" धागे को रखने की कोशिश करने की अनुशंसा करता हूं। यह धागा आईओ सीमित होगा। चूंकि यह एक फ़ाइल पढ़ता है, यह प्रसंस्करण करने के लिए "प्रसंस्करण" को थ्रेडपूल थ्रेड (.NET 4 कार्य भी इसके लिए बहुत अच्छा काम करता है) में धक्का दे सकता है, जो इसे तुरंत अगली फ़ाइल को पढ़ने की अनुमति देगा।

यह कम से कम रनटाइम से "प्रसंस्करण समय" लेगा, जिससे आपके काम के लिए कुल समय डिस्क IO जितना तेज़ होगा, बशर्ते आपके पास काम करने के लिए अतिरिक्त कोर या दो मिल जाए ..

+0

लॉल बस मैंने क्या कहा। बड़े मन वाले ऐसा सोचते हैं – Icemanind

2

मैं क्या करूँगा एक अलग थ्रेड में प्रसंस्करण करना है। मैं एक फाइल में पढ़ूंगा और कतार में डेटा स्टोर करूंगा, फिर अगली फाइल में और फिर आगे पढ़ें।

अपने दूसरे धागे में, धागे ने उस कतार से डेटा पढ़ा है और इसे संसाधित किया है। देखें कि क्या मदद करता है!

0

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

आप Windows का उपयोग कर रहे हैं, मैं NTFS (का उपयोग करते हुए जो निर्देशिका प्रविष्टि ( में छोटे फ़ाइलों संग्रहीत करता है करने के लिए स्विच चाहते हैं लेकिन सीपीयू सस्ते और तेज़ लेकिन कम डिस्क स्थान हैं -> कम पढ़ने का समय); यदि आपकी फ़ाइलें सभी छोटी हैं तो यह प्रासंगिक नहीं हो सकता है। यदि आप वहां हैं तो लिनक्स फ़ाइल सिस्टम समकक्ष हो सकता है।

हां , आपको फ़ाइलों को पढ़ने के लिए धागे का एक गुच्छा लॉन्च करना चाहिए:

 forall filename in list: fork(open filename, process file, close filename) 

आपको आरयू को रोकने के लिए इसे थ्रॉटल करना पड़ सकता है धागे से बाहर निकलना, लेकिन मैं सैकड़ों के लिए 2 या 3 नहीं शूट करूंगा। यदि आप ऐसा करते हैं, तो आप ओएस को बता रहे हैं कि यह डिस्क पर बहुत से स्थानों को पढ़ सकता है, और यह डिस्क प्लेसमेंट द्वारा एकाधिक अनुरोधों को ऑर्डर कर सकता है (elevator algorithm), और यह भी प्रमुख गति को कम करने में मदद करेगा।

0

मैं इस समस्या को हल करने के लिए "बहु थ्रेडिंग" की अनुशंसा करता हूं। जब मैंने आपके पोस्ट उत्तर पढ़े, अचानक पाया कि रीड कॉपसी का जवाब इतना उत्पादक होगा। आप इस समाधान के लिए नमूना पा सकते हैं जो इस link पर Elmue द्वारा तैयार किया गया है। मुझे उम्मीद है कि यह उपयोगी हो सकता है और Reed Copsey के लिए धन्यवाद।

0

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

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