मल्टीकोर टेक्स्ट फ़ाइल पार्सिंग

मेरा अनुभव जावा के साथ है, सी # नहीं, इसलिए माफी माँगती है अगर ये समाधान लागू नहीं होते हैं।

तत्काल समाधान जो मैं अपने सिर के ऊपर से सोच सकता हूं, वह एक निष्पादक होगा जो 3 धागे चलाता है ( निष्पादक .newFixedTreadPool , कहें)। इनपुट फ़ाइल से पढ़ने वाली प्रत्येक पंक्ति / रिकॉर्ड के लिए, निष्पादक पर नौकरी को बंद करें ( execorService .submit )। निष्पादक आपके लिए अनुरोध कतार देगा, और 3 धागे के बीच आवंटित करेगा।

शायद बेहतर समाधान मौजूद हैं, लेकिन उम्मीद है कि यह काम करेगा। :-)

ईटीए: वोल्फबाइट के दूसरे समाधान की तरह बहुत कुछ लगता है। :-)

ईटीए 2: System.Threading.ThreadPool .NET में एक बहुत ही समान विचार की तरह लगता है। मैंने कभी इसका इस्तेमाल नहीं किया है, लेकिन यह आपके समय के लायक हो सकता है!

यह एक धागा पढ़ने की बाधाओं को खत्म कर देगा:

open file
for each thread n=0,1,2,3:
    seek to file offset 1/n*filesize
    scan to next complete line
    process all lines in your part of the file

चूंकि बाधा आम तौर पर प्रसंस्करण में होगी और फाइलों से निपटने के दौरान पढ़ने पर नहीं, मैं निर्माता के साथ जाऊंगा -कंस्यूमर पैटर्न। लॉकिंग से बचने के लिए मैं लॉक फ्री सूचियों को देखता हूं। चूंकि आप सी # का उपयोग कर रहे हैं, आप जूलियन बकनल के लॉक-फ्री सूची कोड पर एक नज़र डाल सकते हैं ।

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

या यदि आप चाहें, तो एक पाठक थ्रेड लाइनों को तीन अन्य प्रोसेसर थ्रेड (अपनी स्वयं के कतारों के माध्यम से) असाइन करें और कार्य-चोरी रणनीति । मैंने कभी ऐसा नहीं किया है इसलिए मुझे नहीं पता कि यह कितना मुश्किल है।

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

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

@lomaxx

@Derek & Mark: I wish there was a way to accept 2 answers. I'm going to have to end up going with Wolfbyte's solution because if I split the file into n sections there is the potential for a thread to come across a batch of "slow" transactions, however if I was processing a file where each process was guaranteed to require an equal amount of processing then I really like your solution of just splitting the file into chunks and assigning each chunk to a thread and being done with it.

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

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

प्री-पार्स किए गए डेटा भाग (जहां आप पहले से ही सभी स्ट्रिंग तुलना और "टोकननाइज्ड" कर चुके हैं) को कोड के उस हिस्से में पारित किया जा सकता है जो वास्तव में टोकनयुक्त डेटा के अर्थशास्त्र और ऑर्डरिंग को देखेगा।

साथ ही, आप उल्लेख करते हैं कि आप अपनी फाइल के आकार से बड़ी मात्रा में स्मृति पर कब्जा कर रहे हैं। आपके मेमोरी बजट पर कटौती करने के लिए आप कुछ चीजें कर सकते हैं।

फ़ाइल को टुकड़ों में विभाजित करें और इसे पार्स करें। जैसा कि आप एक समय में काम कर रहे हैं, उतने ही हिस्सों में पढ़ें, कुछ "आगे पढ़ें" के लिए, इसलिए जब आप अगले खंड पर जाने से पहले एक खंड को संसाधित करते हैं तो आप डिस्क पर रुकते नहीं हैं।

वैकल्पिक रूप से, बड़ी फ़ाइलों को स्मृति मैप किया जा सकता है और "मांग" लोड। आप और अधिक धागे सीपीयू से फ़ाइल को संसाधित करने पर काम कर है, तो (आमतौर पर धागे = 1.5-2X CPU के मांग पृष्ठन क्षुधा के लिए एक अच्छी संख्या में है), धागे कि स्मृति मैप की गई फ़ाइल के लिए आईओ पर रोकने कर रहे हैं जब तक ओएस से स्वचालित रूप से रुक जाएगा उनके स्मृति के लिए तैयार है और अन्य धागे प्रक्रिया जारी रहेगी।