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