近期在做
node.js的
LuaJIT port。
LuaJIT是當(dāng)前已知最快的腳本JIT編譯器，拿來做服務(wù)器再好不過。
發(fā)現(xiàn)node.js底層所用的庫
libuv簡直是個(gè)神器，包含了網(wǎng)絡(luò)、文件系統(tǒng)、計(jì)時(shí)器等等一堆堆的有用功能，windows、linux、MacOS等均支持，而且是純C的API，和LuaJIT結(jié)合會(huì)比較友好，理論上不用任何額外的C代碼，依靠
ffi庫就可以搞定，經(jīng)過
試驗(yàn)也確實(shí)如此，于此同時(shí)發(fā)現(xiàn)LuaJIT也真神器也，居然可以直接把Lua函數(shù)當(dāng)做C函數(shù)指針傳進(jìn)去當(dāng)回調(diào)！正當(dāng)我躊躇滿志的準(zhǔn)備跑下性能測試就開始做上層封裝的時(shí)候，結(jié)果楞了：
1、Lua版的idle示例，等待一個(gè)idle事件被調(diào)用1e7（一千萬）次，在C下只需要區(qū)區(qū)0.1秒，在lua下需要足足30秒多！并且內(nèi)存在這個(gè)過程里猛漲猛漲再猛漲，最后的gc過程耗費(fèi)了更久的時(shí)間！
原版的在
這里，Lua版的在
這里。
2、嘗試添加1000次idle事件，LuaJIT直接報(bào)錯(cuò)：too many callbacks
3、其他不同的嘗試均體現(xiàn)，性能嚴(yán)重不過關(guān)。
然后在ffi的說明里發(fā)現(xiàn)了
這個(gè),提到了幾個(gè)問題：
1、callback占用某些總量有限的系統(tǒng)資源，所以用過的callback需要釋放，并且同時(shí)存在的callback只能有500-1000個(gè)。
2、callback函數(shù)不會(huì)被自動(dòng)gc，需要用一些麻煩的辦法手動(dòng)來釋放
3、callback會(huì)很慢。文中提到了類似于lua_call的消耗及argument marshalling的消耗。這點(diǎn)會(huì)在下面詳細(xì)講述。
總的來說，luajit里的callback，是在內(nèi)存里生成了一小段代碼，這小段代碼的功能是把參數(shù)轉(zhuǎn)換好，然后再調(diào)用對(duì)應(yīng)的lua函數(shù)。（還有一些奇奇怪怪的開銷，我個(gè)人認(rèn)為這才是主要開銷，后面會(huì)詳細(xì)講述），因此有同時(shí)存在的總量上限（雖然我也不明白為什么就因此了，但大致就是那么回事吧），并且很慢，很慢，很，慢，很……慢……
基本上，解決方法就那么幾種：
1、做一些特定的封裝，用C額外編寫一個(gè)函數(shù)做一些處理，在這個(gè)函數(shù)里用其他方式（lua_pcall等）去調(diào)用，這樣調(diào)用參數(shù)的類型會(huì)受限一些。經(jīng)測試這個(gè)只能提升50%左右（距離之前的300倍差距還差得遠(yuǎn)……），主要是還有一些關(guān)鍵的開銷（在下面詳細(xì)講述）無法避免。
2、改寫被使用的C庫，拒絕回調(diào)，用其他辦法實(shí)現(xiàn)。這是LuaJIT官方所推薦的，原文如下：
For new designs avoid push-style APIs: a C function repeatedly calling a callback for each result. Instead use pull-style APIs: call a C function repeatedly to get a new result. Calls from Lua to C via the FFI are much faster than the other way round. Most well-designed libraries already use pull-style APIs (read/write, get/put).但像libuv這樣的庫，改寫難度有些大……關(guān)鍵在于重新設(shè)計(jì)整個(gè)結(jié)構(gòu)為pull-style很困難，同時(shí)會(huì)導(dǎo)致相關(guān)文檔廢棄，增加了額外的工作量。
3、小幅度改寫使用的C庫，公開一些必須的內(nèi)容，然后把其中的一部分在lua里實(shí)現(xiàn)，確保所有callback調(diào)用的時(shí)機(jī)均在lua中，廢棄掉原始的C API。這樣相對(duì)來說不用改變?nèi)魏蔚慕涌冢枪ぷ髁恳膊恍。Q于庫的復(fù)雜程度。
最終我在node.lua中選擇了方案3。事實(shí)證明效果確實(shí)很好，在還有一些會(huì)帶來額外開銷的功能沒加進(jìn)去的情況下，之前的test優(yōu)化到了0.08s左右，預(yù)計(jì)全部完成后開銷在0.15s之內(nèi)，很接近純C實(shí)現(xiàn)的性能。
然后我又做了若干實(shí)驗(yàn)，并且在freelist里和LuaJIT的創(chuàng)始人Mike請(qǐng)教了一會(huì)，得到了一些結(jié)論：
1、回調(diào)的argument marshalling是重大瓶頸之一。雖然不知道為什么，Lua對(duì)C的調(diào)用，返回值的marshalling性能很高，我推測是由于原因3。
2、把Lua-function cast成C function pointer是另一重大瓶頸，如果存在反復(fù)的類型轉(zhuǎn)換，這里會(huì)很要命。這里包含了之前所說的生成指令序列的開銷，但cast本身也會(huì)具有巨大的開銷，我嘗試將一個(gè)C function cast成 C function pointer，都帶來了極大的開銷。據(jù)Mike說，這個(gè)開銷也是原因3導(dǎo)致的
3、導(dǎo)致程序運(yùn)行很慢的原因，歸根結(jié)底：某些行為會(huì)導(dǎo)致JIT失效！在沒有JIT的情況下，本身運(yùn)行性能差不多就有幾十倍的損失，再加上一些額外開銷會(huì)因此被放大，最后就得到了不可接受的性能損失……
最后總結(jié)，目前應(yīng)該在LuaJIT的ffi庫中避免使用函數(shù)指針，使用Lua本身來封裝回調(diào)函數(shù)（如果接口需要），方可獲得LuaJIT提供的卓越性能。