使用FILE_FLAG_NO_BUFFERING能够带来显著的速度提升吗？

Question

最近注意到MSDN中FILE_FLAG_NO_BUFFERING标志的详细描述，并阅读了几篇有关Windows中无缓冲I/O的Google搜索结果。

http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx

我现在想知道，在文件I/O编程中考虑无缓冲选项是否真的很重要？因为许多程序使用普通的C流I/O或C ++ iostream，所以我以前没有注意过FILE_FLAG_NO_BUFFERING标志。

假设我们正在开发类似于Picasa的照片浏览器程序。如果我们实现无缓冲I/O，那么缩略图显示速度是否会对普通用户产生明显的差异？

- 9dan

---

对两个答案都点赞，谢谢！我用我的旧照片浏览器项目测试了缓冲和非缓冲文件加载。由于它只是顺序读取的场景，所以没有明显的速度变慢，也找不到任何明显的加速。 - 9dan

我认为可以肯定地说，非缓冲文件I/O与最终用户应用程序无关 :) - 9dan

Answer 1

哦，主啊。使用该标志会使其明显变慢。它绕过了文件系统缓存，那个能够以几乎预知的精准度猜测出您在读取 N 之后会想要读取扇区 N+1 的精彩代码。如果获取便宜，它只会预加载。

对于写入来说尤其糟糕，这就是为什么存在该选项的原因，因为您无法得到懒惰的写回。这意味着您的程序只能以磁盘写入的速度运行。这非常，非常慢。该标志的好处在于您可以确保已写入。有助于实现事务性磁盘更新，这是 dbase 引擎关心的类型。

但是请自己尝试一下以查看效果。

- Hans Passant

Answer 2

不，这个标志不适用于普通磁盘用户。它适用于像数据库这样需要执行自己的文件缓存管理以获得最佳性能的程序。虽然我相信你可以找到一些情况下它会加速你的程序，但大多数情况下你应该使用操作系统提供的缓存 -- 这就是为什么它存在的原因。

- Gabe

---

我必须表示不同意。使用操作系统提供的缓冲区在服务器之间复制40 GB文件，会导致服务器内存耗尽并变得非常缓慢。这在生产环境中非常糟糕。我们必须在服务器之间复制大型数据库文件时使用此标志。 - Brain2000

你反对什么？我说“这是为了需要执行自己的文件缓存管理以获得最佳性能的程序”，而你提供了这样一个程序的例子。听起来你实际上同意我的观点。 - Gabe

如果关闭缓存属于“执行自己的文件缓存管理”，那么是的，我同意你的看法。 - Brain2000

文件缓存在单个文件复制时爆炸只与Vista/2008（不包括R2）有关，因为它们的缓存处理非常糟糕。每个后续版本都更加智能地处理它。 - SilverbackNet

Answer 3

我最近尝试了这个。由于我已经在自己实现缓冲区管理（使用解析器中常用的缓冲区对），因此我想 FILE_FLAG_NO_BUFFERING 可能会通过避免额外拷贝来提高效率。我尝试了不同的（页面对齐的）缓冲区大小，但它总是比不使用标志更慢。

由于我的方案涉及按顺序一次性读取整个文件，所以我尝试使用 FILE_FLAG_SEQUENTIAL_SCAN，这实际上有些帮助。

当你禁用缓存时，你就没有预取和其他操作系统使用的缓存技巧的优势。当你给出正确的“提示”，如 FILE_FLAG_SEQUENTIAL_SCAN，那么你就可以充分利用这些操作系统特性。

- Adrian McCarthy

Answer 4

从快速SSD读取大于RAM的文件可以受益于此选项，因为文件无论如何都不适合缓存，而直接IO可以防止不断折磨缓存的开销。这意味着，如果您为大型照片和视频集合创建数千个缩略图，在某些情况下可能是有意义的。

- Dieter Weber