单就文件分割这个访问模式来说，内存映射应该无法提速。

“内存映射有性能优势”这个（不一定正确的）观点在不少地方都有，比如
《Code Quality: The Open Source Perspective》这书的memory mapping相关章节：
https://books.google.com/books?id=vEN-ckcdtCwC&pg=PA241&lpg=PA241&dq=createfilemapping+buffer&source=bl&ots=sI7od62UsI&sig=ACfU3U3EZ07tJMaPnqXW4DgYHkHuZOS4lQ&hl=zh-CN&sa=X&ved=2ahUKEwj8gfnX0MfoAhXhoFsKHZarAoUQ6AEwCHoECAsQLQ#v=onepage&q=createfilemapping%20buffer&f=false

下面这个分析和结论我觉得不错：哪种方式性能好是取决于访问文件的模式的。
而且他有个观点跟你的一致，就是内存映射方式写代码简单 :)
https://unix.stackexchange.com/questions/474926/how-does-memory-mapping-a-file-have-significant-performance-increases-over-the-s/475014

如果是文件分割操作，在windows平台上，读取大文件时最好加上FILE_FLAG_SEQUENTIAL_SCAN这个优化的标志，虽然不一定保证能提速。

windows文件操作的另一个标志FILE_FLAG_NO_BUFFERING（亦即所谓的direct I/O）也是被误解的。这个标志虽然越过了文件系统的cache，但不一定能提速。具体的分析可以参考：
https://devblogs.microsoft.com/oldnewthing/20140306-00/?p=1583
https://stackoverflow.com/questions/4574996/using-file-flag-no-buffering-will-return-noticeable-speed-gain

比较好的文件操作方式是异步，这是下面这个对比帖子说的方案。
因为可以尽可能腾出cpu干别的事情，但文件分割这个需求也不需要腾出cpu干别的事情。
至于耗费cpu进行压缩解压，就不在讨论之列了。
https://www.gamasutra.com/view/feature/1565/fast_file_loading_pt_1.php?print=1


【 在 puke 的大作中提到: 】
: 用内存映射就是图个简单，提速这个说法不知道是谁猜的。
: 如果还要不停的手动映射文件不同区域，这还不够费事的。
--
修改:z16166 FROM 123.115.134.*
FROM 123.115.134.*