少用for，儘量用numpy/pandas的向量化方法。

少用自己寫的python方法，先看看numpy /pandas是不是已有現成的功能。

有幾個numpy 的加速包，比如numexpr.

安裝Intel MKL.

最後，可以講關鍵部分用c/c++實現。

如果無法避開python的for，建議使用Numba來提速，理想情況下可以達到和numpy向量化差不多的速度。

我只能幫你到這裡了||-_-

不會，python雖然相教於編譯型語言執行效率不高。但是其開發週日短，上線應用快，擴充套件包豐富，即插即用。其短板完全可以透過升級硬體彌補。而其廣闊的應用場景，通俗易懂的語法，便捷的開發效率，豐富海量的擴充套件包是其他語言無法比擬的。

功夫核心一直都是支援C++編寫策略的。目前的產品形態主要是基於擴大使用者受眾數量來考慮的。任何一款產品，如果不能得到足夠的使用者數量都是無法生存的，所以對我們來說，就必須在效能和產品易用性之間找到一個平衡點。純粹考慮效能，當然是C++，作業系統深度定製，高階網絡卡，FPGA一步一步往上碼效能會更好，但問題是這樣做，有多少使用者是真正需要的？這樣做，最後一定是淪為一個純定製專案，格局太小了。

功夫本身的定位是一款通用產品而不是某種神奇的技術實現，需要先理解這一點。你如果把它當成一個產品來用，需要考慮的是產品的設計語言是否符合你的業務需要，產品本身的架構是否能長期可持續升級，擴充套件性是否足以支撐未來多種多樣的策略需求，或者大道至簡的說這產品究竟有沒有幫你節省掉你不願意花費的時間？在這些考量裡，功能、速度佔的權重其實都是沒那麼大的，因為這些總可以隨著開發的推進而逐漸實現或提高，關鍵在於這產品的基礎是不是足夠紮實，三天兩頭推翻重來的東西才是最要命的。

舉個實際的例子。在一個自動化交易系統裡，很可能同時執行若干個策略，每個都有幾十幾百個限價單，這個時候市場突發狀況，你需要立刻一鍵停止策略並撤掉這些單子，並且正確維護各個策略的交易記錄。我相信對絕大多數交易者來說，需要的就是這麼一個直觀的按鈕而已，點下它世界安靜，沒有人真的有興趣想研究到底觸發了那些計算機訊號，記憶體硬碟上的資料快取到底怎麼維護，網絡卡收發了哪些包。就這麼一個操作，你猜猜底層實現的工程量有多少？怎麼做能保證在各種操作環境下以各種方式使用它都能正確執行（同時還不影響正常情況下的系統執行速度）？如果你用的產品從根本上就無法支援這樣的操作，你還會願意長期使用嗎？

諸如此類的問題還有很多。如果從這個角度思考，你會發現其實這個行業根本沒有多少人真正理解IT、產品和工程這些概念，有太多產品從根本上設計的就是錯的，實現更是到處給自己挖坑，太多人的時間精力浪費在不知所謂的地方。如果一個需要在市場上撕殺、靠交易盈利的人天天琢磨計算機原理還引以為豪，我都想象不出還有什麼比這更浪費的行為，但現實就是這行業裡還挺常見。

最後回到問題，沿著我上面講的邏輯，功夫現在的產品形態，就是為了讓更多人能夠開箱即用，甚至連Python都不需要自己額外安裝，就可以直接切入到策略開發和執行，在這階段浪費的那點速度其實根本不算什麼；而後續隨著業務升級， 各種作業系統定製、綁核、網絡卡定製甚至FPGA方案都可以在後臺無縫切換，這一切也都是在不影響策略開發體驗的情況下提供的。簡言之，如果你的交易人生是場馬拉松，功夫要能從起點陪你到終點，這也是我們堅持做這個東西的核心邏輯。