要直接回答您的問題:您可以將文件完全加載到內存流中,然後使用您的CsvReader從該流重新讀取。同樣,你可以爲你的文件流創建一個更大的讀緩衝區,例如15MB,這將在整個文件中讀取整個文件到緩衝區。我懷疑這其中的任何一個都不會改善10MB文件的性能。
找到真正的性能瓶頸:從磁盤讀取文件內容的時間,將CSV解析爲字段的時間,還是處理記錄的時間?一個10MB的文件看起來非常小。我使用自定義csv閱讀器處理250MB + csv文件的集合,沒有任何投訴。
如果處理是瓶頸,並且您有多個可用線程並且您的csv文件格式不需要支持轉義換行符,那麼您可以將整個文件讀入行列表(System.IO.File.ReadAllLines/.ReadLines)並使用不同的任務解析每一行。例如:
System.IO.File.ReadLines()
.Skip(1) // header line. Assume trusted to be correct.
.AsParallel()
.Select(ParseRecord) // RecordClass ParseRecord(string line)
.ForAll(ProcessRecord); // void ProcessRecord(RecordClass)
如果你有很多文件解析,可以處理不同任務中的每個文件,並使用異步方法來最大限度地提高吞吐量。如果它們都來自同一個物理磁盤,那麼你的milage會有所不同,甚至可能比單線程方法更糟糕。
更先進:
如果您知道您的文件包含8位字符而已,那麼你就可以在字節數組操作,跳過StreamReader的開銷投字節到字符。通過這種方式,您可以在一次調用中將整個文件讀入一個字節數組,並假設不需要支持換行符轉義,就可以掃描換行符。在這種情況下,掃描換行符可以由多個線程完成,每個線程都查看字節數組的一部分。
如果您不需要支持字段轉義(a,「b,c」,d),那麼您可以編寫更快的解析器,只需查找字段分隔符(通常爲逗號)即可。如果存在瓶頸,您也可以將字段分界解析和字段內容解析分割爲線程,但內存訪問局部性可能會否定任何好處。
在某些情況下,您可能不需要將字段解析爲中間數據結構(例如雙精度,字符串),並且可以直接處理對字段開始/結尾的引用並節省一些中間數據結構的創建時間。
好的.NET流已經使用緩衝,所以你確定這是問題嗎?文件有多大?您可能想嘗試** async **方法 – MickyD
其每個文件大約10 MB – junkone