程序员思考过程:确定在使用Windows API的ReadFile时要读取的最大字节数

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]

要读取的最大字节数.

我对这里的"神奇数字"并不感兴趣,但经验丰富的程序员需要确定放在那里的数字,最好用数字步骤.

还要记住我在汇编程序中编写程序,所以从这个角度来看,我对思考过程更感兴趣.

---

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

Answer 1

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

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

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