在Winodws上以磁盘的最大速度持续存储二进制文件

hellioncu

回复  happy_fish100

是，测试的程序很简单，malloc一块内存，70MByte，对齐到sector大小。反复执行ope ...
notbusy 发表于 2010-03-08 12:17

    循环里面只做write试试

notbusy

回复 5# irp

谢谢回复。我看了你给的链接，里面讨论了异步文件读写方法。
做了实验，结果是690ms，70MByte，101MByte/sec，速度没有明显提高。

1. VirtualAlloc(NULL, SIZE_70M, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
   
2. ...
   
3. CreateFile(filename, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH | FILE_FLAG_OVERLAPPED, NULL);
   
4. ...
   
5. WriteFile(hFile, p, SIZE_70M, &nwritten, &overlap);

复制代码

我不明白为什么要issues多个异步写。
1. 在应用程序里我用一块连续内存做图像缓冲区，在写入之前已经全部准备好了。
2. 我可以分出一个CPU Core单独用于文件写入。即，不需要利用磁盘写入的空闲时间来完成其他任务。

如果使用异步写，我可以想到的理由是把要写的内存分成几块，比如2块。一半儿一半儿。
然后用2个异步写同时写入两块数据到文件里，第二块儿的文件Offset用overlap.Offset指定。测试结果也是没有明显的速度提升。

另外我发现，在用_write()写入的时候用TaskManager看CPU，有一个Core的CPU利用率非常高，但是用WriteFile的时候，没有这种现象。
_write()的速度大概在400ms一下。


fwrite和_write是CRT(C RunTime)函数，最后都要用Windows API的WriteFile来写入文件。
不明白在大块数据无缓冲区写入的情况下，为什么_write会比WriteFile还快。

notbusy

循环里面只做write试试
hellioncu 发表于 2010-03-08 13:44

你是考虑open/close的时间太长吗？我测了一下没有写入的情况，一次open/close平均是0.75ms。如上所述open/write/close的平均是700ms左右，所以时间还是写入文件用掉了。

irp

WriteFile ( 70M ) 对kernel的mm会有影响，所以建议分成小的块比如4, or 8M来分成多个io request, 另一方面在多核的情况下，可以并发issue io. 不过你的case 产生io数据的速度<磁盘速度，所以这应该不是主要
因素。可能用SetFileValidData先分配好磁盘空间会有帮助。

notbusy

谢谢各位的回复，特别是irp的建议，帮我提供了调查的线索和很重要的参考资料。下面把我调查的结果总结如下，给后来者提供参考。
首先，HALCON的写入速度277MByte/sec是测试的错误。我偶尔发现在HALCON执行完了之后磁盘还有2，3秒的读写时间。所以事实上HALCON并没有把写入的数据commit(sync)到硬盘上，而是写到了System Cache里。

我用第三方工具Performance Test 评价版的测试结果是C盘速度103.5MByte/Sec。和我下面的测试结果基本吻合。

1. 测定方法
先执行200次是为了WarmUp测试环境。

1. 
   
2. 分配内存
   
3. Loop 200回
   
4.     文件Open
   
5.     文件写入
   
6.     Sync到硬盘
   
7.     文件Close
   
8. Loop End
   
9. Loop 5回
   
10.     测定开始
    
11.     Loop 100回
    
12.         文件Open
    
13.         文件写入
    
14.         Sync到硬盘
    
15.         文件Close
    
16.     Loop End
    
17.     测定结束
    
18. Loop End
    

复制代码

2. 内存对齐
    分别用malloc和VirutalAlloc分配内存，来比较内存对齐对速度的影响。

3. 结果汇总
比较low-level i/o (_open/_write/_commit/_close)，Stream i/o (fopen/fwrite/fflush/fclose)，Windows API i/o (OpenFile/WriteFile/CloseHandle)的速度。其中fopen时使用'c' flag保证在flush缓冲区的时候OS把System Cache， commit到硬盘缓冲区里。

1. 
   
2. Throughput(MByte/Sec)
   
3. Method                          C:盘    G:盘
   
4. _write/_commit(malloc)          83.3    87.7
   
5. _write/_commit(VirtualAlloc)    83.7    86.5
   
6. fwrite/fflush(malloc)           102.5   107.5
   
7. fwrite/_commit(malloc)          99.1    107.6
   
8. fwrite(malloc)                  104.4   108.1
   
9. fwrite(VirutalAlloc)            97.7    109.0
   
10. WriteFile(VirtualAlloc)         99.1    107.6
    

复制代码

4. 结果分析
4.1 Low-Level I/O (_write)最慢，这和预想有差别，因为是大块binary data的写入，我原来以为Stream I/O会慢，因为需要1. 把内存存入UserSpace的库Buffer里，然后2. 存入KernelSpace的SystemCache里，最后3. 写入磁盘Buffer里。Low-level省掉了第一步，我认为应该更快。也许库对大块的binary data做了优化，比如取消了库buffer，同时通过调整写入块的大小和次数提高了速度。
4.2 Windows API (WriteFile)不比Stream I/O更快。
4.3 通过对齐应用程序持有的内存，并不能保证吞吐量的提高。
4.4 G盘比C盘快，原因是Paging File(swap)在C盘有12GB，PageIn/PageOut消耗了时间。
4.5 最快的方法是用fwrite把对齐的内存写入G盘。Throughput是109.0MByte/Sec。
4.6 Cross Platform的malloc和fwrite方法与最高速度差距不大，推荐。

safedead

你的阵列能够有300MB/S的写入速度????
指标相当NB的阵列啊
结果最后是100MB/S的实际写入速度
明显被卖阵列的给蒙了

有100MB/S的写入速度,读取勉强能到300MB/S
想要更快就得投入更多

wesleyluo

学习的！