Python mmap 读取大文件：少拷贝不等于一定更快
一、mmap 适合什么问题
Python 处理大文件时，mmap经常被认为是高性能方案。它把文件映射到内存地址空间，让程序像访问内存一样访问文件内容，减少显式 read 调用和用户态拷贝。但少拷贝不等于一定更快。
如果访问模式是顺序读、小文件读、一次性全量解析，普通 buffered IO 可能已经足够。mmap更适合随机访问、重复扫描和需要切片读取的大文件场景。
二、读取路径要看访问模式
flowchart TD A[大文件读取] --> B{访问模式} B -->|顺序扫描| C[Buffered IO] B -->|随机访问| D[mmap] B -->|重复切片| D B -->|流式处理| C C --> E[端到端 Benchmark] D --> E不要只比较单次读取耗时。解析、解码、对象创建和下游计算也会影响端到端性能。
三、最小示例
import mmap with open("data.bin", "rb") as f: with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm: head = mm[:128] pos = mm.find(b"target") print(head, pos)mmap返回的是字节视图，后续如果频繁转换成 Python 对象，仍然会产生开销。
四、Benchmark 要覆盖冷缓存和热缓存
文件系统缓存会显著影响结果。第一次读和第二次读可能差很多。评测时要区分冷缓存、热缓存和不同文件大小，不要拿一次结果下结论。
还要注意地址空间。32 位环境或内存限制严格的容器里，映射超大文件可能失败。mmap映射的是虚拟地址空间，不代表物理内存立刻占满，但仍然受系统限制影响。
文本处理场景要考虑编码边界。按字节切片可能切断多字节字符，导致解码失败。二进制格式更适合直接 mmap，文本格式需要额外设计切分策略。
最后，mmap 文件关闭和生命周期要清晰。仍有 memoryview 或切片引用时关闭映射，可能出现异常。资源管理不严谨，性能优化会变成稳定性问题。
并发读取也要单独测试。多个进程同时 mmap 同一个大文件，可能共享页缓存，性能表现很好；但如果同时做随机访问，也可能造成大量缺页和磁盘抖动。访问模式比 API 选择更关键。
还要关注内存峰值的误读。mmap会占用虚拟地址空间，监控里看起来进程虚拟内存很大，但 RSS 未必同样大。排障时要区分 VIRT、RSS 和 page fault，不要看到虚拟内存大就误判为泄漏。
在数据处理管线里，mmap 常和索引文件配合。先建立记录偏移，再按偏移随机读取，能避免全量扫描。没有索引时，mmap 只是换了一种读法，算法复杂度并没有改变。
最后，端到端评测要包含解析结果校验。优化 IO 后，如果切片边界或编码处理错了，速度再快也没有意义。性能测试和正确性测试应该一起跑。
在机器学习数据管线中，mmap 常用于特征文件或样本索引。此时还要验证随机采样是否均匀、worker 之间是否重复读取、文件句柄是否被正确继承。DataLoader 多进程环境下，资源生命周期比单进程脚本更复杂。
如果数据需要压缩，mmap 的收益会下降。压缩文件通常不能任意字节随机访问，除非额外建立块索引。评测时要把原始文件、压缩文件和索引化压缩文件分开比较。
五、总结
Pythonmmap适合大文件随机访问和重复切片，但不是所有读取场景的默认答案。Benchmark 要看访问模式、缓存状态、解析成本和资源生命周期。少拷贝只是手段，端到端更快才是目标。
