编程与软件工程jakevdp.github.io
Python 为什么慢：深入底层
Why Python Is Slow: Looking Under the Hood
2014 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Jake VanderPlas 的经典文章，从 CPython 的实现层面剖析 Python 为什么慢：动态类型导致每个对象都携带大量元信息、解释器开销、缺乏值类型等。文章用图示展示了 Python 对象在内存中的实际结构，说明慢的根源在于语言设计上的灵活性代价。
为什么经久不衰：它把“Python 慢”从模糊印象变成可理解的底层机制，多年后仍是理解动态语言性能权衡的最佳入门读物。
HN 评论精选
Perl 同为解释型却快得多，说明慢的根源是 Python 的对象模型而非解释执行本身
一个相关的问题是：为什么 Perl 那么快？多年前我用 Perl 写过一个 Runge-Kutta 求解器做模拟，单次运行要花几个小时。后来我用 C++ 重写，速度提升却不到两倍。所以问题不在于“Python 是解释型语言”，Perl 同样是解释型的。关键在于 Python 的对象模型——Perl 的标量类型开销小得多，甚至能做相当高效的数值计算。我后来还是因为 Python 写起来更有趣而转向了它，但 Perl 的速度确实让我怀念，也让我意识到解释型语言不一定慢。
tjradcliffe查看英文原文
A related question is: why is Perl so fast? Quite a few years ago I wrote a little Runge-Kutta solver in Perl for some simulation work. It seemed like a good idea at the time. The equations of motion had to be integrated over a very long time, and it could take hours for a single run (still much faster than the Monte Carlo it was being used to do a sanity-check on). I re-wrote everything in C++, and picked up less than a factor of two in speed. So it isn't that "Python is interpreted" that is the problem, because "Perl is interpreted" in exactly the same way. It really does seem to come down to the Python object model. Perl's scalar types have vastly less overhead, so much so that you can actually do reasonably efficient numerical computation in it. I abandoned Perl for Python shortly thereafter because once I got over the "oh my god it's full of whitespace" thing Python was just more fun to code in, but the speed that Perl provided is something I've definitely missed, and it was a real awakening to the notion that interpreted languages don't have to be slow. The striking thing was that unlike Java (say) where it can be fast but you generally have to think about it, I was getting fast Perl without even really trying.
慢不是动态类型的必然代价，而是 CPython 等解释器实现质量差
这篇文章有误导性。Python 及类似的慢速动态语言（Perl、PHP、Ruby）慢并不是因为动态类型检查、分支和间接跳转代价高，而是因为解释器本身写得差：低效的指令和数据结构。而 Lisp、Scheme、Lua、JavaScript 等高效的动态语言是存在的。关于高效解释器的经典论文是 Ertl 的《The Structure and Performance of Efficient Interpreters》。
rurban查看英文原文
Unfortunately this blog post is misleading and uninformed. Python and the related other slow dynamic languages perl, php, and ruby are slow not because the dynamic type checks, branches and indirections are costly, but because they are badly written. They are just inefficient and poor interpreters, with bad ops and data structures. In comparison efficient dynamic languages like lisp, scheme, lua or javascript and many others not so well known do exist. Mine, potion, is also in the lua category, and not in the slow PPPR (python, perl, php, ruby) category. The seminal paper about efficient dynamic interpreters is Ertl's "The Structure and Performance of Efficient Interpreters" http://www.complang.tuwien.ac.at/papers/ertl%26gregg03jilp.ps.gz The abstract is: "Interpreters designed for high general-purpose performance typically perform a large number of indirect branches (3.2%–13% of all executed instructions in our benchmarks). These branches consume more than half of the run-time in a number of configurations we simulated. We evaluate how accurate various existing and proposed branch prediction schemes are on a number of interpreters, how the mispredictions affect the performance of the interpreters and how two different interpreter implementation techniques perform with various branch predictors. We also suggest various ways in which hardware designers, C compiler writers, and interpreter writers can improve the performance of interpreters." My own input to this is that the GC, the JIT, the calling convention and esp. the size of the datastructures and ops do matter more, than eliminating the type checks.
CPython 团队不重视性能，Python 3 错失了提升性能的机会
更大的背景是：CPython 核心团队根本不太在乎性能，性能从来不是基本要求，只是事后考虑。Python 3 就是最大的证明——他们本可以限制 Python 过度的动态行为、加入可选类型标注、允许原地操作和预分配来避免反复堆分配，这些都能让 Python 更快、更易 JIT，但都没发生。Python+Cython 依然强大，但最终 Julia 或类似语言会在科学计算领域抢走 Python 的饭碗。
amit_m查看英文原文
The bigger picture is that CPython's core team simply does not care too much about performance. Performance has never been a fundamental requirement, but merely an afterthought. The biggest reminder of this was Python 3, which for me was a complete disappointment. They could have limited python's super-dynamic behavior (e.g. changing builtin functions, patching classes on the fly, etc.) or made them optional. They could've added optional typing annotations a la Cython. Or even changing the builtins and language syntax to allow more inplace operations and preallocations, so that temporary results wouldn't have to be allocated on the heap over and over again. All of these changes would have made python faster and more JIT-able. None of these things happened. Performance-wise, python 3 is no step forward. Python+Cython is still a powerful combination, but eventually Julia or similar languages will eat python's lunch with respect to scientific computing.
语言性能差距源于商业投入，而非技术上的不可逾越
Python（和 Ruby）慢是因为没有哪家价值数十亿美元的公司被最初的语言选择困住、被迫投入巨资优化。PHP 和 JavaScript 曾经极慢，但在几千万美元砸向 JIT、重写和重新设计之后，现在快得多了。
VeejayRampay查看英文原文
Python (and Ruby for that matter) are slow because there are no billion-dollar companies stuck with an initial choice of language that impedes their ability to grow. PHP and Javascript used to be extremely slow and now after several dozens of millions thrown at JIT, rewrites, forks and redesigns they're starting to get much much faster.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选