如何改进通用 I/O 以与文件映射保持一致
文件映射很棒，但对于 32 位系统上相对较大的文件，我们应该忘记它并使用通用文件 I/O 来实现所有内容。对于大型随机读取和写入，系统缓存的工作效果几乎与文件映射一样好。但对于小文件区域周围的小操作，差异是巨大的，文件 I/O 比文件映射文件的等效操作慢十倍。后者主要是因为多次调用 SetFilePointer、ReadFile、WriteFile，甚至是几个小操作。
所以我想实现或使用某种缓存（或者可能是一些技巧），它应该可以有效地处理小型读/写，但我不需要一些复杂的缓存，因为对于大型操作，Windows 做得很好。有一些已知的方法吗？
谢谢马克斯
File mapping is great, but for comparatively large files on 32-bit system one should forget about it and implement everything with general file i/o. For large random reads and write the system cache works almost as good as file mapping. But for small operations around small file areas the difference is huge, file i/o is ten times slower than the equivalent actions for file-mapping files. The latter mostly because of multiply calls for SetFilePointer, ReadFile, WriteFile even for several small actions.
So I would like to implement or use some kind of cache (or maybe some trick) that should work effectively for small reads/writes but I don't need some complex one since for large operations Windows is doing a great job. Is there some known approach to this?
Thanks
Max
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
回复我自己的问题，供其他人在将来考虑类似的方法
看起来最好的是支持文件上的多重缓冲映射视图。在这种情况下，数组允许快速访问指向内存块（vies）的指针，如果基于请求的偏移量计算的指针有效，则应该只访问数据，如果不是，则分配新视图，可选地保留视图总数到一定限度。我在阅读和写作方面相对较快地实现了这一点，结果非常有希望
Replying to my own question for other to consider similar approach in the future
Looks like the best is to support multiply buffered mapped views on the file. In this case an array allows fast access to pointers to memory blocks (vies) and if the pointer calculated based on a requested offset is valid, then one should just access the data, if not - then allocate new view optionally keeping total number of views to certain limit. I implemented this comparatively quickly for both reading and writing and the results are very promising