效率優化的高速處理

一般來說程式通常會被期待有優雅的結構化.物件化,有時候是基於可讀跟維護的需求,有時候是風格問題,但以我所知,一層又一層的結構化.物件化雖然對軟體設計.規劃和維護有幫助,但需要高速與效率處理時,結構化與物件化往往是不利的,雖然現在硬體快速,不同往年,不太需要錙銖計較,但如果真的遇到效能瓶頸,還是需要打破風格與慣例問題,特別是模擬器需要大量的計算,在某些部分的處理會是關鍵,每種語言的最佳化作法,可能跟語言或是編譯器.直譯器有些不同,但很多時候卻也是相通的,底下的一些經驗分享是以C#為主,但別語言或許也可通用(需要測試).

1.迴圈開展 :

這也是破壞結構優化處理速度的一個方式,通常跟畫面的輸出有關係,因為遊戲畫面是一個二微陣列,常常需要處理兩層式迴圈 ( for x 與  for y ) , 如果把一層展開,直接用hard code的方式 copy paste下去,效率提昇會非常非常多,展開兩層的方式如果再一定數量內 (tile 8x8共 64次上算尚可接受),效率會提升更多.

2.method開展 :

method的往返需要處理stack的push pop,以及數值傳遞,這些都需要花上處理的時間,而且所佔是相當高的,如果是存取頻繁的method,並且也只出現在幾個少數地方,而且method內的code並不多,可以考慮把method的內容提出,直接寫,不要再多一層method結構包覆.

3.不要使用語言提供的高階的物件 :

方便歸方便,但絕對是效能殺手,能夠避免用到就避免用到,另外一定要用到像是Bitmap,在set pixel 與  get pixel 也一定要用特殊方法去存取
參考 http://www.vcskicks.com/fast-image-processing.php
其實上面的優化還是不太夠, Color 這物件也要避免使用才對.


總之效能優化這事情,常常會跟優雅風格.結構化.物件化產生衝突,一般來說開發初期還是得注意到結構問題,但開發完成後如遇到瓶頸,就需要特殊手段來處理.

上面1.2.3都用過stopwatch測試過,差異非常大.

http://www.dotnetperls.com/optimization 這篇也是可以參考的一文.

其實模擬器需要處理的狀況,比較相似於編解碼器撰寫,C#的效能以現在的硬體條件來說,絕對可以處理過往比較舊的遊戲主機模擬(以我個人推測包括PS1,GBA本身,和它們之前主機都是OK的),只是在一些部分需要注意一下,過度層層結構化.物件化加上使用一堆高階的語言物件,會掛掉.

PS.VisualStudo編譯時開啟Optimize Code選項是基本常識了,另外在debug模式下執行也會降低效率,實測以非debug模式為主.

這篇只是初略寫,以後有更多心得和整理會繼續更新.