Python读取千万级整数文件4种写法的性能差异解析

问题1解答 #

map搭配内置函数int时，整个迭代、类型转换逻辑都在CPython的C层面执行，完全避免了Python字节码循环的开销：不需要在Python层面做变量绑定、函数调用栈帧创建，执行效率远高于Python字节码实现的列表推导循环。
至于增量差值的差异：readlines返回的是预先生成的字符串列表，迭代列表的开销远低于迭代文件对象（文件迭代需要处理IO缓冲、行分割逻辑）。列表推导的循环是Python层实现，会放大迭代器本身的开销差异，所以增量比C层实现的map高2-3倍。

问题2解答 #

是的，这个差值就是10^7个字符串的总开销。
带readlines的列表推导执行时，会先调用readlines把所有行读成一个字符串列表，这个列表会持有所有行字符串的引用，直到整个列表推导执行完成才会被回收。而直接迭代文件对象的列表推导，每次只加载一行字符串，转成int之后该行字符串就没有引用，会被立即回收，不会累积所有字符串的内存。
64位CPython中，每个短字符串本身的对象开销+字符存储平均约60字节，10^7个刚好对应600MiB左右的内存差，和测试结果吻合。

问题3解答 #

你观察到的85MiB差值是初始错误测试的结果，和memory_profiler的统计逻辑限制有关。
memory_profiler只能统计Python层面显式创建的对象内存，readlines返回的列表本身的存储开销就是10^7个指针（每个8字节，约76MiB）加列表对象 overhead，刚好和85MiB吻合，但C层面map执行过程中持有的字符串内存没有被统计到。
修正测试方法后两种map写法的内存差实际和列表推导组一致，都是600MiB左右，和字符串总开销匹配。

问题4解答 #

CPython中map是C实现的内置函数，返回一个惰性迭代器：迭代时才会逐个从传入的可迭代对象取元素，调用传入的处理函数返回结果。如果处理函数是C实现的内置函数（比如这里的int），整个执行流程完全在C层完成，不会产生Python层的函数调用、变量绑定开销。
初始内存测试不符合预期的原因是：memory_profiler通过注入Python字节码钩子统计内存分配，map的C层执行逻辑、临时内存分配不会触发钩子，所以统计不到完整的内存占用，只能统计到readlines返回的列表结构这类显式Python对象的内存。

问题5解答 #

内存分析工具的increment字段代表两次采样时间窗口内的内存变化量，负值代表这段时间内释放的内存大小超过了新分配的内存大小，通常是因为没有引用的大对象被垃圾回收器回收了。

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