Python 为什么这么慢？真凶不只是 GIL

Python 为什么这么慢真凶不只是 GIL你在网上可能听过无数遍“Python 慢是因为有 GIL全局解释器锁。”于是你心安理得地想哦那等到多解释器出来或者我用多进程它就该快起来了吧真的不是这样。GIL 只负责让你在多核心上“有劲使不上”但 Python 单线程跑计算本身就慢得不正常。同样的纯计算任务C 比 Python 快 10~50 倍Rust 快几十倍就连同样动态类型的 JavaScript也能比 Python 快 2~5 倍。这些速度差异和 GIL 没有任何关系——因为单线程不受锁的影响。今天我们就用讲故事的方式把 Python “基因里的慢”彻底拆解开。即使你没有计算机体系结构基础看完也能明白原来 Python 的慢是刻在它最根本的设计哲学里的。一、所有东西都是“盒子里的盒子”——Python 对象的真面目从 C 语言的整数说起在 C 语言里定义一个整数int a 42;只做两件事在内存里划出 4 个字节通常直接存下数字 42。这 4 个字节可以放在 CPU 的寄存器里或者紧挨着其他变量放在栈上访问速度极快。C 语言的数据就像一张便利贴写上数字直接贴在电脑桌面上随时能看。Python 的整数一个庞大的档案袋在 Python 里写a 42底层发生的事要复杂得多。CPython官方 Python 解释器会创建一个类型为PyLongObject的结构体它至少包含三样东西引用计数ob_refcnt8 字节 —— 记录有多少个变量在用它。类型指针ob_type8 字节 —— 指向“我是整数”这件事的说明书。真正的数值ob_ival8 字节 —— 存着 42。而且这个结构体并不是直接放在紧邻着其他数据的地方而是从操作系统的“堆”内存里单独申请一块空间就像你每次需要一张纸条都跑去仓库领一个标准公文袋再把纸条装进去。整个公文袋至少 28 字节为了存一个 42。这个画面是不是已经很可怕了但这才刚刚开始。为什么说“堆分配”是性能灾难当你建立一个包含 1000 个整数的列表时C 语言一个连续的 4000 字节数组所有数字肩并肩躺在内存里。Python1000 个独立的“公文袋”散落在内存各处列表本身存的是 1000 个指针就是公文袋的地址。当你需要遍历这个列表把每个数加起来C 语言CPU 可以一次预读一大块数据到缓存顺序访问就像生产线上的零件排好队流过来。PythonCPU 先读一个指针根据地址去找公文袋打开公文袋翻出数字再放下去找下一个地址……每一次访问都可能跳到内存里完全不相干的位置。现代 CPU 缓存对此根本无法预测会频繁发生“缓存未命中”cache miss每次未命中都好比工厂要停工一百多个时钟周期去仓库取料生产线立刻慢成乌龟。这就是你听到的“所有数据都在堆上很难放进 CPU 缓存”的通俗解释。Python 对象的内存布局天生就是碎片化、胖存储的这是它慢的第一重根源。二、动态类型的代价——每一步都在“猜”猜错就倒大霉加法到底怎么做CPU 猜得头疼对于a bC 语言在编译时就能确定a、b 都是int直接生成一条加法机器指令CPU 到达这里二话不说就加上流水线畅通无阻。Python 则完全不同。因为变量没有固定类型上一秒a是整数下一秒可能变成字符串所以 CPython 执行a b时必须走一个极其曲折的流程找到a的公文袋看它的类型指针哦是个整数。找到b的类型指针也是整数好调用整数加法函数。但如果b是字符串呢那就得抛异常或者调用不同类型对应的函数。哪怕都是整数加法内部还要检查会不会溢出要不要把结果从“小整数”升级成“长整数”对象。这个过程的每一步在 CPU 眼里都是条件分支if-else。现代 CPU 为了高速执行会像赌徒一样提前猜一条路跑下去这叫“分支预测”。如果猜对了流水线继续飞起如果猜错了已经跑到一半的指令全部作废清空流水线重新加载代价十几到几十个时钟周期。Python 这种动态分发每次操作的类型都可能不同CPU 的分支预测器根本建立不起规律预测失败率高得惊人流水线反复被打断。这就是“操作造成流水线停顿、分支预测失效”的真实含义。用生活场景比喻快递分拣员想象你是一个快递分拣员面前有过不完的包裹。每个包裹外面都贴着“易碎品”“普通件”“冷藏”等标签你需要根据标签把包裹送去不同通道。静态类型语言C/Rust上午所有包裹都是“普通件”你看都不用看闭着眼睛往右扔就对了。动作极其顺畅。动态类型语言Python每个包裹都可能换标签你每拿起一个都得翻过来仔细看标签判断送去哪条通道而这个判断本身就要暂停手上的动作思考一下。要是偶尔判断错了还得追回来重来。Python 的程序执行过程就是这样频繁地停顿、判断、改道自然快不起来。三、字节码分发——翻译官逐字念稿的效率CPython 是个“解释器”不是“编译器”当你的 Python 代码运行时CPython 并不是直接转化成 CPU 能懂的机器码而是先变成一套叫作“字节码”的中间指令然后在一个巨大的循环里一条一条执行。这个循环在 CPython 源码里叫ceval.c就是著名的“解释器主循环”。可以这样比喻编译语言如 C、Rust是直接把剧本交给演员演员拿到的是详细的、现成的动作指令上台就演。解释型 Python则是一个翻译官他看着剧本读一句“LOAD_FAST 0”然后自己理解一下哦是把本地变量 0 取出来压到栈上“BINARY_ADD”哦是把栈顶两个数加起来……每一步都要经过“取指令→理解指令→执行”的过程。这个翻译官读剧本本身要花时间而且读每条指令都要在那个巨大循环里跳转又是一大堆分支。这就是“字节码分发开销”。为什么 JavaScript 能快那么多JavaScript 也是动态类型脚本语言但它背后有 V8Chrome 的 JS 引擎这样的高性能虚拟机。V8 做了几件 CPython 没做的事情JIT 即时编译检测到热点代码比如一个循环被跑了很多次直接把这段代码编译成本地机器码下次再执行就跳过翻译官直接给演员剧本。字节码分发开销一下子就没了。隐藏类和内联缓存V8 发现“这个对象总是被当成同一种结构使用”就偷偷给它分配一个固定布局把属性访问变成固定偏移量的内存读取省掉了反复查字典、做分支判断的过程。而 CPython 仍然老老实实每次查字典。小整数优化V8 把常用的小整数直接编码到指针里不用单独创建对象完全省掉了堆分配和内存碎片。这些优化正好是对症下药地解决了我们前面说的“堆分配、动态类型、分支预测”问题。所以 JavaScript 比 Python 快 2~5 倍是完全合理的它用工程能力在很大程度上抵消了动态语言的先天劣势而 CPython 为了简单、可维护性刻意没有加入这些复杂优化。四、整合起来看单线程 Python 到底慢在哪我们现在可以把“让你 Python 单线程跑得慢”的三个元凶排成一列肥胖的对象与糟糕的缓存局部性一切数据都是堆上的对象紧凑的数据消失了CPU 缓存总是白忙碌访存成为瓶颈。无处不在的动态分发与分支预测失败每次操作都要查类型、选函数CPU 流水线被频繁打断预测失败不断发生。解释器循环的固定门票每条字节码都要经过主循环分发额外吃掉一层指令开销而没有 JIT 加速。当这三者叠加哪怕是最简单的整数循环Python 花在“读懂指令、找对象、判断类型”上的精力远大于真正做加法的那一下。这就是为什么有 C 程序员调侃“Python 是一个极好的抽象层只不过为了这份抽象你要付几十倍的税。”五、GIL 呢它在这些慢面前只是“配角”现在你应该能区分开了GIL是一个同步锁导致多线程在 CPU 密集任务上无法利用多核心。上述三个原因则是 Python 解释器执行本身的效率低下让你单核就跑得慢。如果把 Python 比喻成一辆车GIL 是车上装了个限速器使得在高速公路上多核你也只能占用一条车道。而对象的堆分配、动态分派、解释循环决定了这辆车本身就是一辆大货车自重三吨发动机还是小排量在市区单核跑也远远跑不过别人家的小轿车。所以即便 Python 3.13/3.14 开始有办法绕过 GIL自由线程、多解释器Python 单线程的计算速度也不会因此质变仍需要寄望于“Faster CPython”这类项目在解释器层面优化那些根因。而如果你想做数值密集型计算现实的最优解依旧是用NumPy底层用 C 写成规避 CPython 的对象开销或者直接写 C 扩展。结语慢是选择而非缺陷Python 的“慢”根植于它最宝贵的特性极致的动态性、高度一致的“一切皆对象”模型以及解释器实现的简单可维护性。这种设计让 Python 变得易学、易写、易读但代价就是 CPU 时间的浪费。理解这些底层原因后你就不会再奇怪为什么一个简单的循环比 C 慢几十倍也不会寄希望于某个新特性能瞬间让 Python 变成火箭。你会更明智地知道什么时候该用 NumPy什么时候该换 PyPy什么时候该把性能敏感部分用 C/Rust 重写什么时候就安心接受 Python 的便利用它的慢来换你的开发效率。毕竟工具的选择永远是权衡。而我们已经清楚知道天平的两端到底放着什么。