最近研究了下Python的代碼，有了一些新的發(fā)現(xiàn)。大量的內(nèi)置字符串常量沒有做Intern優(yōu)化，在python源碼中搜索形如"__dict__"之類的常量是這么用的：

PyObject* xxxObject = PyObject_GetAttrString(someObject, "__dict__");

這樣會導(dǎo)致每次調(diào)用到這里時都會去查找一下有沒有創(chuàng)建過這個字符串。實際上對于腳本虛擬機中這類常量應(yīng)該提前分配好，直接使用PyObject引用，而不是每次都嘗試去創(chuàng)建一個。要命的是GetAttrString在很多基礎(chǔ)操作中會大量使用…… lua對這些字串則都緩存了起來。

在Python 3之后，python使用了_Py_Identifier緩存了一些靜態(tài)名字，使得這部分性能得到了一定的優(yōu)化。

2. 使用RC和TRACE的GC方案導(dǎo)致需要大量，頻繁地增減計數(shù)器。lua沒有這個開銷。

3. Python 中調(diào)用函數(shù)會把參數(shù)打包成一個tuple，頻繁創(chuàng)建和刪除tuple造成比較大的開銷(雖然內(nèi)部對tuple有緩存機制，但是仍然會增加約10%的消耗)。Python 2中instancemethod會導(dǎo)致重新打包一次tuple再去call，加重了這個問題。實際上由于Python不支持多線程，在有些情況下可以使用復(fù)用這些tuples的，沒必要每次都重新創(chuàng)建。lua則直接在lua_State的棧上展開了參數(shù)，不需要打包數(shù)組。

4. 運算符的調(diào)用鏈和需要處理的動態(tài)情況過多，導(dǎo)致自定義一個支持運算符的類型的性能極差。相比lua的metatable少量的table查找，python的實現(xiàn)極其復(fù)雜。有興趣地童鞋可以看看PyNumber_Add的實現(xiàn)。

5. 對輕類型的支持不好，為了OOP實現(xiàn)得太重了。這一點其他答案說得比較多，這部分主要是內(nèi)存消耗和是否走GC的差異，在這方面lua的內(nèi)置類型number/lightuserdata不走gc的優(yōu)勢很明顯。

6. 虛擬機實現(xiàn)上的差異，lua register-based VM可以讓指令的數(shù)量少很多。Python這方面天然比較吃虧且沒有什么簡單的解決辦法。

7. C-API效率上python的api比較難用，而使用封裝好的綁定庫會進一步增加API調(diào)用上的開銷。一個簡單地讀取自定義C對象中某個屬性的操作，從發(fā)起調(diào)用到讀到對應(yīng)屬性的半程操作中(不算寫回到腳本)，Python有80%的時間花費在調(diào)用鏈和數(shù)據(jù)轉(zhuǎn)換上，相比Lua只有50%左右。

后面的想到再說~

總的來說，如果把腳本語言比作一個垃圾處理站，那么Python就是不管你要扔什么垃圾，統(tǒng)一都通過一個入口倒進去，然后垃圾處理站內(nèi)部再用復(fù)雜的流程去分類處理。而Lua會預(yù)設(shè)幾個大的門類，常用的紙箱飲料瓶專窗背后直接對接再生制品的工廠，廚余垃圾專窗背后直接對接飼料場，剩下的再走復(fù)雜流程。

大多數(shù)情況下，來倒垃圾的都在lua預(yù)設(shè)的那幾個大門類里。

最后貼一下Python和Lua在如下幾個方面實測的效率差異吧，平臺Windows 64Bit：基礎(chǔ)數(shù)值計算：Lua速度是Python的10-15倍

與宿主語言交互：Lua速度是Python的3-5倍

字符串操作：兩者差不多

綜合性能：具體取決于代碼中各種操作的比例，實際效果Lua一般在Python的2-4倍之間。

總結(jié)

以上是生活随笔為你收集整理的python lua 性能比较 内存_Lua 的速度为什么比 Python 快？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。