2010-06-04 12 views
5

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

  1. चेक अगर फ़ाइल खोला जा सकता है (IOException पकड़ने) और यह एक bool [] अगर कोई अपवाद नहीं फेंक दिया जाता है के रूप में सुलभ बंद निशान।
  2. सत्य चिह्नित फ़ाइलों की सरणी के माध्यम से जाकर, रीडलाइन विधि का उपयोग कर फ़ाइल की प्रत्येक पंक्ति को StreamReader में पढ़ें। चूंकि एप्लिकेशन कभी-कभी हिचकिचाहट करता है और खत्म नहीं होता है, इसलिए मैं यह कहने के लिए IOException का उपयोग नहीं कर सकता कि फ़ाइल पूरी हो गई है या नहीं - मुझे वास्तव में पाठ को पार्स करना है।
  3. यदि पाठ को पूरा करने का संकेत मिलता है, तो फ़ाइल को ज़िप करें, संग्रहीत फ़ाइल को NAS पर लोड करें, और मूल को हटाएं।

मेरा कोड काम करता है, यह बहुत समय ले रहा है (लॉग फाइलें प्रत्येक 500 एमबी के आसपास हैं)। सुधार पर मेरे विचारों में शीर्ष से की बजाय फ़ाइल के नीचे से मेरी खोज शुरू करना शामिल है, लेकिन StreamReader ऐसी विधि का समर्थन नहीं करता है। मैं ReadToEnd विधि का उपयोग नहीं कर सकता और फिर रीवर्स पढ़ सकता हूं क्योंकि यह सिर्फ स्मृति अपवाद से बाहर फेंकता है। किसी भी विचार पर मैं लॉग फ़ाइल की पार्सिंग तेज कर सकता हूं?

+0

आप जानते हैं कि फ़ाइलों को पार्स धीमी हिस्सा है है की तरह कोड के साथ किया जा सकता है? ज़िपिंग नहीं, NAS को प्रतिलिपि बनाना, फ़ाइल को खोलने या हटाने की कोशिश करना (और संभावित रूप से असफल) उन सभी चीजों की आवाज़ जैसे ध्वनि – luke

+0

संभावित डुप्ली: http://stackoverflow.com/questions/452902/how-to-read -ए-टेक्स्ट-फ़ाइल-रिवर्सली-साथ-इटेटर-इन-सी –

+1

अच्छा सवाल। हाँ, यह निश्चित रूप से पार्सिंग है जो निष्पादन का समय लेने वाला हिस्सा है। मैंने व्यक्तिगत कार्यों में कोड को अलग किया और प्रत्येक पर ब्रेक पॉइंट डाला। ज़िप में लगभग 30-30 सेकंड लगते हैं, पार्सिंग दो घंटों तक ऊपर ले जा सकती है। – monkeyninja

उत्तर

6

मुझे लगता है कि यह फ़ाइल समाप्त होने के बाद फ़ाइल के अंत में एक मार्कर की तलाश है या नहीं? यदि ऐसा है तो मैं यह भी मानता हूं कि मार्कर ज्ञात लंबाई का है, उदाहरण के लिए एक बाइट या 3 बाइट्स का अनुक्रम इत्यादि।

यदि उपर्युक्त धारणाएं सही हैं, तो आप फ़ाइलस्ट्रीम, Seek फ़ाइल के अंत में खोल सकते हैं अपेक्षित मार्कर लंबाई से कम बाइट पढ़ते हैं और यदि मार्कर मौजूद है और आपको पता है कि आप फ़ाइल को संसाधित कर सकते हैं।

अंत करने के लिए की तलाश -3 बाइट्स निम्नलिखित

// Seek -3 bytes starting from the end of the file 
fileStream.Seek(-3, SeekOrigin.End); 
+0

अनुक्रमिक पढ़ने और एकाधिक खोज करने की तुलना में एक महंगा ऑपरेशन हो सकता है काफी धीमा हो सकता है। – josephj1989

+0

ऐसा कुछ है जो मैंने अभी तक नहीं किया है, हालांकि यह एक शॉट के लायक है। मैं तलाश को लागू करने की कोशिश करूंगा और देख सकता हूं कि क्या चीजें गति को बढ़ाती हैं या नहीं। सबको शुक्रीया। – monkeyninja

+3

@ जोसेफ 1 9 8 9, क्या आप कह रहे हैं कि 500 ​​एमबी फ़ाइल लाइन लाइन या मेमोरी फ्रेंडली हिस्सों में पढ़ने के लिए तेज़ी से अंत तक सीधे अंत तक खोजना है? और क्यों कई खोजते हैं, मेरी कहा गया धारणा यह है कि मार्कर फ़ाइल के अंत में है, इसलिए केवल एक ही तलाश है। –

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