我有一個動態分配的數組,其中包含有1700萬個元素的struct
。將其保存到磁盤上,我寫fwrite()性能遠低於磁盤容量
fwrite(StructList, sizeof(Struct), NumStructs, FilePointer)
在後面的步驟我用等效fread
聲明讀它,就是使用sizeof(Struct)
和NumStructs
計數。我期望得到的文件將大約3.5 GB(這是所有x64)。
是否有可能通過sizeof(Struct) * NumStructs
作爲大小和1
作爲計數來加速?我爲什麼寫入操作可能需要分鐘在32 GB RAM(大量寫入緩存)的快速計算機上寫着我的腦袋。我已經運行了自制基準測試,並且緩存足夠積極,第一個800 MB到1 GB的典型值爲400 MB /秒。 PerfMon顯示它在fwrite期間佔用了一個內核的100%。
我看到here這個問題,所以我問的是,fwrite中是否存在一些循環,可以通過告訴它寫入1個大小爲n * s的元素而不是n個元素來「欺騙」大小爲s。
編輯
我在釋放模式和兩次我放棄了等待跑這兩次。然後我以調試模式運行它,知道通常運行時間會更長。要寫入的數據的確切大小是4,368,892,928字節。在所有這三種情況下,PerfMon都會顯示兩次間隔30秒的磁盤寫入活動,然後CPU達到100%的一個內核。該文件在那個點上是73,924,608字節。我在fwrite
的任一側都有斷點,所以我知道它就在那裏。看起來似乎有些東西卡住了,但我會讓它在一夜之間運行並看看。
編輯
離開這個過夜,在fwrite
肯定掛,文件從來沒有過去的70 MB。
你試過了嗎?爲了防止緩存阻礙,您可以使用其他應用程序佔用其他內存。 – Mysticial
更改這樣的參數不會影響性能;如果寫入很短,它只會影響錯誤報告。國際海事組織將不會有太多的事情可以改善性能。您只需要一次呼叫即可將系統呼叫開銷降至最低;從那裏,這是o/s能夠多快分配3.5 GiB磁盤空間的問題。您可以查找系統調用以預配置文件大小並儘可能接近地進行分配,但這非常適合平臺。我看到你的標籤中有Windows;我不能幫助更多...... –
如果你的程序正在燃燒100%的核心,那麼它不會被磁盤陷入困境。這使得你認爲它與fwrite()有很大關係。不信任任何反惡意軟件並使用分析器。 –