我正在使用ReadFileEx（使用CreateFile和FILE_FLAG_NO_BUFFERING标志打开）从文件中读取扇区对齐的块，记录调用之前的开始时间，以及完成例程中的结束时间（来自QueryPerformanceCounter的时间） ）。
无论整个文件的大小如何，我的块读取的大小都是不变的。块偏移按顺序排队，因此ReadFileEx始终在文件中读取比最后一个点更远的点。我注意到一些奇怪的行为，这样较小的文件记录的块读取时间比较大的文件快得多。
在这种情况下，较大文件的大小是较小文件的两倍 - 我不应期望这在原始数据读取级别上很重要，因为我正在读取相同大小的块。我所看到的是较小的文件报告160mb / s读取，较大的文件报告110mb / s。
我仍然在假设我的代码中的其他内容导致问题。我还希望在ReadFileEx + GetLastError返回ERROR_IO_PENDING之后，在某些操作系统定义的点开始读取操作。
编辑：通过调整我的读取线程进一步确认了我的计时不准确性，因此它有更多的时间等待处于完成挂起通知的可警告状态。这增加了报告的读取速度，表明我的部分问题是读取完成后不会立即调用完成处理程序（因此我的结束时间晚于应该的时间）。但是，这样做会增加较大和较小文件的报告速度。
TL; DR 我的问题是，我可以测量读取操作的实际时间，而不是调用ReadFileEx（可能无法直接读取）之间的时间离开）和完成程序？
答案 0 :(得分：3)
TL; DR我的问题是，我可以衡量吗？ 读操作的实际时间， 而不是打电话之间的时间 ReadFileEx（可能无法启动 直接读完）并完成 常规？
可能不是来自用户模式代码。
您控制之外的变量太多了。您不知道可能需要什么样的搜索（例如，一个文件可能被分段，另一个文件可能不分段）。文件映射（文件段到磁盘块）可能已缓存，也可能尚未缓存。即使没有读取缓冲区，仍然存在群集，驱动器上的查找重新排序，驱动器上的缓存等。通过异步操作，您还可以使用调度程序。
使用驱动程序，您可以进行一些精确的测量，但是您仍然需要运行大量实验并计算平均值以获得统计结果，从而计算出驱动器内发生的所有奇怪事情（重试，重新排序） ，使用备件，板载缓存，区域位记录，热重新校准等。）。