为何C++代码读取1MB图片的耗时远超HDD标称读取速度？

• 代码存在编译级别的硬错误：
  • 字符类型拼写错误：unsinged char正确写法应为unsigned char
  • 变量引用错误：前面计算得到的文件大小变量名为fsize，但后面申请缓冲区时写的new unsigned char[size]属于引用未定义的size变量，这段代码实际无法通过编译。
• 缺少必要的错误校验：
  • 未校验fopen的返回值，如果文件不存在、无读取权限，后续操作会直接对空指针解引用触发崩溃
  • 未校验fread的返回值，无法确认实际读取到缓冲区的字节数
  • 申请的堆缓冲区未在使用后释放，存在内存泄漏
  • 32位环境下ftell对超过2GB的文件会出现值溢出，无法获取正确的文件大小
• 以上问题主要影响代码的鲁棒性，并非造成100~200ms高读取耗时的核心原因。

你之前测得的80MB/s HDD读取速度，是机械硬盘的峰值顺序读取速度，这个数值的测试场景和你日常读1MB小文件的场景存在本质差异，不能直接拿来做耗时推算：

• 峰值速度的测试前提是：磁头已经稳定在目标磁盘位置、文件已经被系统预热到内存页缓存、测试文件为连续分布的大尺寸文件（通常至少几百MB），此时磁盘不需要反复寻道，才能跑满80MB/s的线性速度。
• 而你读单个1MB未被缓存的小文件时，需要承担大量和传输带宽无关的固定开销：
  • 机械磁盘的物理固定延迟：磁头移动到目标磁道的寻道时间（通常5_{15ms）、等待盘片旋转到目标扇区的旋转延迟（通常2}5ms），这部分开销加起来就已经接近你推算的12.5ms的总耗时
  • 文件系统元数据开销：读取文件前需要先定位文件的索引节点、遍历文件的数据块分布，对于磁盘碎片较多的分区，这部分操作可能触发多次额外的磁头寻道，累计开销可达几十ms
  • 冷读的页缓存未预热：你第一次读取该文件时，操作系统没有提前把文件内容加载到内存页缓存，此时的小文件冷读吞吐量通常只有5_{15MB/s，算下来100}200ms读1MB的耗时是完全符合机械硬盘物理特性的，并非异常。
• 代码使用的C标准IO接口默认仅使用4KB~8KB大小的用户态缓冲区，读1MB内容会触发上百次内核态和用户态的数据拷贝，这部分会额外增加几ms到十几ms的耗时，但仍不足以解释100ms以上的差距。

• 如果文件已经被操作系统预热到内存页缓存，完全可以实现更快的读取：此时不需要访问磁盘，直接从内存拷贝1MB内容的耗时通常仅为1~3ms，远低于理论推算的12.5ms。
• 如果是从磁盘冷读的场景，在HDD上稳定实现12.5ms读1MB是比较困难的——因为磁盘的寻道、旋转固定延迟就已经占去了十几ms，80MB/s的峰值速度需要连续读取几百MB的数据才能达到，无法在仅1MB的小文件读取场景中复现。
• 可以通过以下优化进一步降低读取耗时：
  • 给FILE流通过setvbuf设置1MB大小的用户态缓冲区，减少频繁的拷贝次数
  • 直接调用系统原生IO接口（Linux下的open/read、Windows下的CreateFile/ReadFile），跳过C标准IO层的额外拷贝
  • 打开文件时指定顺序扫描的读入标识，让操作系统提前执行预读操作，减少磁盘寻道的等待时间

内容的提问来源于stack exchange，提问作者LostBoy