2009-10-11 91 views
17

我正在寫一個需要讀取相當大的文件的應用程序。我一直想知道現代Windows XP計算機上讀取緩衝區的最佳大小。我搜索了一下,發現了很多例子,其中最佳尺寸爲1024。最佳文件緩衝區讀取大小?

這裏是我的意思的一個片段:

long pointer = 0; 
buffer = new byte[1024]; // What's a good size here ? 
while (pointer < input.Length) 
{ 
    pointer += input.Read(buffer, 0, buffer.Length); 
} 

我的應用程序是相當簡單的,所以我不打算寫任何基準測試代碼,但想知道什麼大小適用?

+0

可能會有所幫助:http://stackoverflow.com/questions/19558435/what-is-the-best-buffer-size-when-using-binaryreader-to-read-big-files-1gb/19837238? noredirect = 1#19837238 – 2013-11-07 13:34:09

回答

7

1k緩衝區大小似乎有點小。一般來說,沒有「一刀切」的緩衝區大小。您需要設置適合您算法行爲的緩衝區大小。現在,一般來說,擁有一個非常巨大的緩衝區並不是一個好主意,但是,如果它太小或者不符合你處理每個塊的方式也不是那麼好。

如果您在處理數據之前只是簡單地將數據塊逐個讀入內存,我會使用更大的緩衝區。我可能會使用8k或16k,但可能不會更大。另一方面,如果以流方式處理數據,讀取塊並在讀取下一個較小的緩衝區之前進行處理可能會更有用。更好的是,如果您正在流式傳輸具有結構的數據,那麼我會更改讀取的數據量以與您正在閱讀的數據類型特別匹配。例如,如果您正在讀取包含4個字符的代碼,一個浮點數和一個字符串的二進制數據,我會將4個字符的代碼讀取爲4個字節的數組以及浮點數。我會讀取字符串的長度,然後創建一個緩衝區來一次讀取整個字符串數據塊。

如果你正在做流數據處理,我會看看BinaryReader和BinaryWriter類。這些允許您非常容易地處理二進制數據,而不必擔心數據本身。它還允許您將緩衝區大小與正在使用的實際數據分離。您可以在底層流上設置一個16k緩衝區,並輕鬆地使用BinaryReader讀取各個數據值。

+0

感謝您使用BinaryReader的建議。使用BinaryReader有助於讀取字符串,因爲我不需要編寫管道代碼來編寫長度。 我將測試8K和16K讀取以查看性能是否提高。就個人而言,我不在乎尺寸是多少,但一些質量保證人員想要了解我們是否可以通過更好地利用硬件和操作系統來提高性能。 – 2009-10-12 00:52:41

+0

如果您只是將大量數據傳輸到內存中,您可以嘗試更大的緩衝區。只要您將緩衝區大小保持爲磁盤簇大小的倍數,您應該是最佳的。說實話,我認爲我90年代末和2000年初的做法仍然有很深的根深蒂固。如果您正在運行此程序的系統具有現代性和高性能,則32k,64k甚至更大的緩衝區可能會有所幫助。如果你太大(例如1mb),隨着其他因素的增加(即交換顛簸),你可能會看到收益遞減。關鍵是將讀取與低級行爲進行匹配。 – jrista 2009-10-12 05:02:32

3

取決於您在訪問時間和內存使用情況之間劃定界限的位置。緩衝區越大,速度越快 - 但在內存方面更昂貴。 讀取倍數的文件系統簇大小可能是最高效的,在使用NTFS的Windows XP系統中,4K是默認簇大小。

你可以看到這個鏈接Default cluster size for NTFS, FAT, and exFAT

再見。

+0

我會嘗試@jrista建議的8K和16K讀取。有趣的是,這篇文章說windows使用8k羣集的16 TB磁盤分區。我還沒有看到過之前很大的一個分區。 – 2009-10-12 00:56:45

+1

Andrew,8K和16K是4K的多個硬件 – RRUZ 2009-10-12 01:21:03

+0

較舊的硬盤驅動器一次讀取和寫入整個512字節的扇區。現代硬盤驅動器一次可讀寫整個4096字節的扇區。 Windows NTFS有一個4096字節的(默認)羣集大小。使用Windows的事件跟蹤功能,你可以看到Windows最常見的是16,384字節的實際硬盤驅動器I/O以及4,096個字節(以及較少的8192和49152字節)。理想情況下保持4k或16384字節的倍數。 – 2013-10-12 19:55:02