有关file mapping的测试

http://www.iteye.com/topic/46777
这个帖子中说到了file mapping用于大文件读写，因为速度快.
按照我以往个人的认识是: file mapping能够提高大文件读写速度，但是并不是一定要用file mapping来实现.
file mapping的工作原理并不复杂，应该算是一种大的文件数据cache, 大的cache可以使在一定范围内的寻址速度加快，因为数据不需要通过较慢的File IO去操作，而直接使内存读写. 正是这个主要的特性将大大提高随机的读取操作，例如数据库文件的操作就是.
依照这个思想，如果不用file mapping也应该可以实现这种功能.
为了验证自己的观点，我写了一个测试程序，如附件.
总共三个测试方法，分别为:
FileOperation1 - 使用file mapping
FileOperation2 - 常用的文件读写
FileOperation3 - 自定义cache读写
测试的时候产生一个按照扇区总数（BLOCKSIZE/SECSIZE大）的乱序访问顺序，用来模拟实际的随机读取，每个测试程序都根据这个顺序一个扇区一个扇区（这里简单的用SECSIZE设定扇区大小，完善的话就去抓取系统物理扇区的大小）的访问，每个扇区内的数据都逐一读写.
在设定BLOCKSIZE为1MB的时候，得到的测试数据如下
Test1:
Access: 0
Write: 20
Test2:
Access: 3996
Test3:
Access: 0
Write: 20
在设定BLOCKSIZE为10MB的时候，得到的测试数据如下，这时候Test2的速度已经让人难以忍受了
Test1:
Access: 60
Write: 421
Test2:
Access: 39827
Test3:
Access: 90
Write: 311
在设定BLOCKSIZE为100MB的时候，我已经无法忍受Test2了，只对比Test1和Test3
Test1:
Access: 701
Write: 4166
Test3:
Access: 922
Write: 4887
简单三次测试虽然模拟的方式会比file mapping慢一点，但是基本还是在一个档次上的，所以应该可以证实我的判定，剩余速度的差异应该是出在操作系统对file mapping的优化了.
当然我这个测试只是验证了作为cache对速度提升上面，实际操作中file mapping在数据commit上作的优化较多，所以还是推荐使用file mapping访问大文件，但是同样要说file mapping不是处理大文件的唯一途径.

最后提醒...测试的目标文件会被修改，使用产生任何意外与本人无关