為什么動態類型語言相對比較慢？

靜態類型語言中，在聲明變量時已經指定了數據類型和表示方法。動態類型語言是在運行期間檢查數據的類型，不得不保持描述變量值的實際類型標記，程序在每次操作變量時，需要執行數據依賴分支。

而間接分支（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編譯器里，因為類型標記嚴重地降低了運行性能。

快速的數據結構對于內存訪問模式和緩存位置是非常重要的，還可以減少分支和對這些分支的標記工作。