c++ - 程序员思维过程 : determining a maximum number of bytes to read when using ReadFile with the Windows API

Question

我需要调用 Windows API 的 ReadFile 函数:

BOOL WINAPI ReadFile(
  _In_        HANDLE       hFile,
  _Out_       LPVOID       lpBuffer,
  _In_        DWORD        nNumberOfBytesToRead,
  _Out_opt_   LPDWORD      lpNumberOfBytesRead,
  _Inout_opt_ LPOVERLAPPED lpOverlapped
);

我感兴趣的论点是第三个:

nNumberOfBytesToRead [in]

The maximum number of bytes to be read.

我对放在那里的“魔数(Magic Number)”不太感兴趣，但是经验丰富的程序员确定放在那里的数字的过程，最好是按编号的步骤。

另外请记住，我正在用汇编程序编写程序，因此我对从那个角度思考的过程更感兴趣。

---

• https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx

Answer 1

这需要对 Windows 和您的硬件有深入的了解。但是，总的来说，这里有一些可能的方向:

• 写入是缓冲的还是非缓冲的？如果没有缓冲，那么您甚至可能无法选择大小，但必须遵守缓冲区大小和对齐的严格规则。
• 一般来说，您希望让操作系统处理尽可能多的工作，因为它比您在用户空间中对存储设备本身及其各种用户的了解要多得多。因此，如果可能的话，您可能希望一次获取全部内容(请参阅以下几点)。
• 如果事实证明这还不够好，您可以尝试通过尝试各种大小来超越它，以解决您可能能够使用操作系统出于某种原因不会使用的当前缓冲区的情况'总是针对不同的要求使用。
• 否则，您可能会使用介于磁盘扇区大小和页面大小的倍数之间的任何大小，因为这些很可能已经缓存在某个地方，并且还可以直接映射到实际的硬件请求。
• 除了性能之外，还有一个问题是在任何给定时间您可以负担得起在您的进程内存中存储多少。
• 还有发送大请求的问题，这可能会阻止其他进程有机会进入那里并在两者之间获取一些数据——如果操作系统还没有以某种方式处理这个问题的话。
• 还有一种可能性是，通过请求太大的 block ，操作系统可能会推迟您的请求，直到其他进程得到它们不起眼的请求。另一方面，如果是交叉地址，它实际上可能首先为您提供服务，然后再为缓存中的其他地址提供服务。

一般来说，您可能想要尝试直到获得足够好的东西。