7
我目前每個內存塊使用100兆字節來複制大文件。複製時使用的理想內存塊大小是多少？
人們通常使用的「良好」數量？
編輯
感謝所有偉大的響應。
我對這些概念還是比較陌生的，所以我會嘗試去理解很多已經說過的概念（例如寫回緩存）。我不斷學習新的東西:)
A
回答
9
4096和32KB之間的塊是典型的選擇。使用100MB會適得其反。你正在佔用內存，緩衝區可以使用很多作爲文件系統寫回緩存。
當文件完全適合緩存時，複製文件非常快，WriteFile（）調用是一個簡單的內存到內存副本。緩存管理器然後懶洋洋地將它寫出到磁盤。但是當緩存中沒有更多空間時，當WriteFile（）必須等待空間可用時，複製速度纔會下降。它現在以磁盤寫入速度進行。
0
我認爲這取決於你有空閒內存的大小。
如果您在具有例如30Mb空內存的計算機上使用100 M塊進行復制，則需要比使用較小（20M）塊更多的時間進行復制。
如果您的複製buf大於可用空閒內存的大小，那麼由於虛擬內存交換，您的複製將比預期慢。
+0
我不知道這是你的意思，但我檢查文件大小是否大於100兆字節，如果不是，我只是使用確切的文件大小的塊。 – 2011-03-26 21:21:39
0
這是一個相當多的數額。考慮到在讀取100 MB之前你甚至沒有開始寫數據，所以文件系統驅動程序甚至沒有機會在閱讀時編寫任何目標文件。在讀取源文件時，磁盤可能會寫入正好在磁頭下傳遞的文件的部分（例如，請參閱elevator seek）。
2
使用較大的塊通常沒有什麼好處。
假設你的操作系統是超級幼稚，每讀或寫操作招致硬盤尋求（在寫入得到排隊讀練習，你會經常發現獲得預讀緩衝，減少使用大緩存的好處在您的應用程序代碼中）。
然後每個塊花費你（比如說）2x10ms用於兩個搜索（一個讀取和一個寫入），一旦實際讀取和寫入的時間遠遠超過這個時間，則增加塊大小的意義不大。一個非常快的HD可能會以150MB/s的速度讀取和寫入，在這種情況下，10ms將對應於1.5MB的讀取/寫入，而對於超過15MB的塊大小，您將獲得很少的收益。實際上，（1）你的尋找時間可能會更短，（2）你的讀寫帶寬可能會更多，（3）你的操作系統和驅動器硬件可能會緩存和排隊等待你的東西;你可能會看到從大於100KB以上的塊大小中獲益甚微。
（你或許應該基準多種塊大小，看看你自己的系統是什麼。）
5
我會建議你以此爲基準，並記住包括多更小的塊大小。在我自己的測試中，我得到了很不直觀的結果。
當從硬盤讀取和寫入數據時，512字節和512 kB之間的所有（兩個冪的）塊大小給出相同的速度。將塊大小從512 kB增加到1 MB 減少了複製速度到約60％。增加塊大小再次提高了速度，但從未回到使用小塊的速度。
當所有複製的數據都在高速緩衝存儲器中時，複製速度（快得多）隨着塊大小的增加而提高，在達到32kB塊時變平滑，然後當從256 kB到512 kB塊，永不回到以前的速度。
經過這個測試後，我在幾個程序中將讀/寫塊的大小從1 MB降到了32 kB。
+0
有一次（幾年前），當我使用Flash文件系統在移動設備上進行了一系列測試時，寫入速度一直保持在256K左右，儘管64K的回報遞減很快。但是IIRC我只是測試從內存寫入文件，而不是文件文件複製。而我們永遠無法弄清楚這些尺寸的特別之處。 – 2011-03-26 23:15:16
0
鑑於驅動器必須在它改變磁道時進行尋道，可能不是塊尺寸比如63 x 512 = 32256產生最佳結果？
+1
物理磁盤和程序之間有幾層操作系統和硬件，所以磁盤磁道大小可能不重要。但是，歡迎來到SO :-)。 – thiton 2011-11-17 19:02:13
也許您的可執行文件比Windows複製文件具有更高的優先級。 – BenjaminB 2011-03-26 21:18:35
如果你的操作系統提供了'statfs'，那麼你可以看看它建議的塊大小（'f_bsize'），儘管我不知道你能相信多遠，它實際上是「最優」的。除非您真的擔心在不同的平臺和文件系統上會發生什麼情況，否則請在您的機器上運行幾個不同大小的測試，從非常小到非常大。使用更多的內存超過了停止變快的地步沒有意義。 – 2011-03-26 23:11:02
也考慮使用本機操作，例如Windows上的'CopyFile'。 – MSalters 2011-03-28 09:13:17