Reverse Streamreader

我有一個應用程序，我一直負責清理後。應用程序本身相對簡單 - 它運行SQL查詢，使用Web服務，並將結果傳送到日誌文件。我的工作是在應用程序完成後將文件存檔到我們的NAS。它專門鎖定文件直到完成它們，因此增加了一點複雜性。我也不允許觸摸應用程序，只是日誌。反正我的應用程序相當簡單：Reverse Streamreader

檢查文件是否可以打開（趕上IOException異常），並把它劃掉一個布爾[]如果沒有異常被拋出訪問。
瀏覽標記爲true的文件數組，使用ReadLine方法將文件的每一行讀入StreamReader。由於應用程序偶爾打嗝並且沒有完成，我不能簡單地使用IOException來判斷文件是否完成 - 我必須實際解析文本。
如果找到指示完成的文本，則壓縮文件，將存檔文件加載到NAS中，然後刪除原件。

我的代碼工作，它只是非常耗時（每個日誌文件大約500 MB）。我對改進的想法包括從文件底部開始搜索，而不是從頂部開始搜索，但StreamReader不支持這種方法。我不能使用ReadToEnd方法，然後反向讀取，因爲這隻會引發內存不足異常。任何想法，我可以加快解析日誌文件？

來源

2010-06-04 monkeyninja

你知道解析文件是緩慢的部分代碼來完成？沒有ziping，複製到NAS，刪除或嘗試打開文件（並可能失敗）所有這些事情聽起來像他們可能需要一段時間 – luke 2010-06-04 17:27:05

可能dupe：http://stackoverflow.com/questions/452902/how-to-read -a-text-file-reversely-with-iterator-in-c – 2010-06-04 17:36:12

好問題。是的，這絕對是解析，這是執行的耗時部分。我將代碼分成單獨的函數並在每個函數上放置斷點。壓縮需要大約30-45秒，解析可能需要兩個多小時。 – monkeyninja 2010-06-04 17:50:04

我假設你在文件末尾查找單個標記以確定它是否完成？如果是這樣，我還假定標記已知長度，例如單個字節或3個字節的序列等。

如果上述假設是正確的，則可以打開FileStream，Seek到文件末尾減去預期的標記長度讀取字節，如果標記存在並完成，則知道可以處理該文件。

尋求到年底-3個字節可以通過類似以下的

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

來源

2010-06-04 17:25:06

尋求可能比順序讀取更昂貴的操作，並且做多個搜索可能會非常緩慢。 – josephj1989 2010-06-04 17:36:59

這是我還沒有嘗試過，所以這是值得一試。我會嘗試實施這個尋求，看看它是否能夠加快速度。謝謝大家。 – monkeyninja 2010-06-04 17:51:19

@ josephj1989，你是說，閱讀一個500MB的文件，一行一行或者內存友好的大塊文件直到最後才比單純地直接查找最快？爲什麼多次尋求，我所說的假設是，標記是在文件的末尾，所以只有一次搜索。 – 2010-06-04 17:53:43

Reverse Streamreader

回答

相關問題