为什么动态类型语言相对比较慢？

静态类型语言中，在声明变量时已经指定了数据类型和表示方法。动态类型语言是在运行期间检查数据的类型，不得不保持描述变量值的实际类型标记，程序在每次操作变量时，需要执行数据依赖分支。

而间接分支（Indirect branch）和数据局部性（data locality）对于运行时的性能是致命的。

这就是动态语言的JIT编译器基准测试要强调near-C的内循环速度，以及避免大的数据结构和数据处理问题的原因。

我也希望像Python这样的动态类型语言可以变快。我试过用Python来进行传统的服务器编程——“系统语言”领域——但是效果真的不好，我现在考虑用Java重写一个服务器。

因此，我花时间思考如何真正静态地编译Python。毕竟，那是我梦寐以求的编程语言！但当我思考如何将动态类型代码与静态编译Python结合起来时，我遇到了数据变慢的问题：

在动态语言中，通常所有数组中的元素（或其他数据结构）类型各不相同，所以有不同的表示值。因此，这些值都必须被单独存放为堆，而不是顺序地存为数组。这意味着如果对不相邻的内存执行数据依赖分支，则对缓存有更高的要求。

也有一些聪明的技巧，使用变量中的特殊bit，将一些原生类型（像整型）打包成一个类型，类似于指针，但这要求寄存器在操作过程中进行跟踪，会增加开销。

还有一些方法，比如使用JIT编译热路径（hot path）时，如果你直接插入没有标类型的值，而不是在堆里分别标记类型， 那么与JIT编译过的代码的互操作性会降低，如果其他代码改变了数组中的一个值的类型，就会出现非常严重的后果。

我一直在思考，在Python语言中，什么是静态的，什么不是。通过SSTA（统计静态分析）和逃逸分析可以判断，大量正常的程序是静态的。Paul Biggar给了我信心证实我的猜测是正确的，我的Python代码90％都是静态的。

有人会问，那另外的10％呢？通常情况下，我可以让所有的都是静态的，或者想象它被参数类型的限制范围特殊化了。除了Python语言的标准模式，其他模式都由Web服务器分配给基于HTTP方法（如果收到GET请求就称为“get”方法）的Web处理器，这也需要程序员依照switch语句（如elifs的长链）来进行修改。

Robert Harper对“从单一类型静态语言方面，动态语言是如何实现的”这个问题作出了很好的解释，下面这句话是我希望他能进一步进行解释的：

引用

我确信他说的“某些情况”是指遇到non-escaping的情况，因为和后面的执行代码进行交互时，你应该要能够确定escape的类型。

一些动态调用是无污染的——编译器可以从代码检查中发现一些变量（或方法）是动态的，但动态的代码不表示其他变量也是动态的，因为不同类型的变量、方法、成员的存在或缺失都被限制成了可识别的类型（或null）。

但通常编译器是无法从代码检查中发现这些情况的，如果无法追踪到执行的情况，就无法知道代码如何依赖以及如何改变其他静态变量的值。因此，工作中断，所有变量再次变为动态的。

我一直在努力寻找把Monkey Patch（不改变初始源代码来扩展和修改动态语言运行代码的方法）、Set（属性或索引器元素赋值的“访问器”方法）、SetAttr（SetAttr 语句可以为一个文件设置属性信息）等解决办法移植到我虚构的Python编译器里，因为类型标记严重地降低了运行性能。

快速的数据结构对于内存访问模式和缓存位置是非常重要的，还可以减少分支和对这些分支的标记工作。

Jonathan Shapiro的文章Programming Language Challenges in Systems Codes非常棒，我很赞同文中的观点。