python lua 性能比较 内存_Lua 的速度为什么比 Python 快?
最近研究了下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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 赵长江:腾势D9新增订单一天破500台!
- 下一篇: python基础语法whike循环_py