網頁版
https://yekdniwunrealengine.blogspot.com/2019/07/ImproveCPUTimeConcept.html
主旨
筆者過去被指派多次改善CPU效能的項目，累積了一些心得可以分享
因此本系列將以UE4為範例，預計提供一些觀念，標準流程，技巧給大家參考
讓大家都可以更快的入門，避免走一些曾經走過的冤枉路。
本篇不會提到太多UE4相關的技巧，會以效能分析與改善的觀念為主。
隨時審視自己的行為
在作效能改善的過程中，一定要隨時知道自己在改善什麼，
做了這個項目在最佳情況可以改善多少。
不要一股腦兒的投入某個細項，結果其實改善微乎其微。
CPU bound? GPU bound?
本系列要提的是CPU效能的改進，不會提GPU 改進的相關部份。
不過先了解自己的遊戲到底是CPU bound還是GPU bound
絕對是首先最重要的事情。
如何知道遊戲是不是CPU Bound?
在UE4要知道這件事很容易，將你的遊戲放到目標平台上
使用console command "stat unit" 並觀察CPU與GPU佔用的時間
CPU過高就是CPU bound，GPU過高就是GPU bound。
都很高的話，就挑嚴重的先處理吧。
謹記80/20原則
80/20原則是個概念，可以套用在很多的事情上(可以無限上綱的意思)
在這邊提的意思是，大多數程式執行的總時間只在執行少部分的程式碼。
所以我們在做效能改善的時候，只處理少部分的程式碼就可以改善最多的效能。
不要用猜的來改善效能
改善效能的流程請務必從量測效能開始，
偷懶跳過這個步驟，用"直覺"來改善效能的話
下場就是很容易成為80/20原則的反向教材，
花了80%的時間只改善效能的20%。
這是經驗談，就算是有經驗的老手也會中招。
畢竟一個遊戲系統很大，每個人都會知道自己經手的系統哪裡效能不佳。
如果直接分配一段時間(例如一週)，讓每個人改善自己的系統效能。
這種作法是最浪費，最沒有效率的，因為效率瓶頸可能根本就不在某人上。
又例如說某個系統有一段寫法很暴力或是用了很多層迴圈，
花了大把時間去改善，結果這段程式碼只執行一次，也不會影響畫面卡頓。
那麼這個時間應該要省下來去作別的項目。
藉由量測效能估算極限
先從量測效能開始的另一個好處是可以很快知道極限在哪裏。
拿到效能數據，有經驗的話很快就可以預測出要讓fps達標，
總共需要改善多少系統。
就算沒有經驗也可以推估一個大概的方向。
舉例來說，根據量測的結果，現在距離fps達標還有3ms要改進。
佔用前幾名的A系統佔用3ms，B系統佔用1.5ms，C系統佔用0.5ms
尋找各系統的開發者，詢問他們
系統改進方案，是屬於可移除/可改善？
改進難度，是屬於極難/中等/極簡單？
假設評估結果
A是極難/可改善，B系統是中等/可改善，C系統是可移除/極簡單
那麼就可以稍為訂出目標為改善B與C
估算ABC三個系統大概可以改進(0.5+0.5)，代表還有2ms需要找其他系統改進。
亦或是要花時間投資在A項目上。
時間寶貴 更要斤斤計較
很多時候我們沒有太多的時間可以作效能改善
遊戲說不定只有一個禮拜或兩個禮拜就要發了才跟你說現在要調效能
(這不是經驗談，只是假設)
注意量測的目標平台
特別注意你現在的目標是哪個平台，請針對平台處理。
完全不建議在編輯器量測平台，除非你明確知道編輯器與打包後的差異。
如果是server/client架構的話通常效能瓶頸也會差很多，
例如UE4的架構AI幾乎只能在server執行，client不會有AI。
如果現在在意的是client端的FPS，那就直接忘了AI很貴的存在吧
至於有沒有要每次都在目標平台做分析，這個我反而持保留的態度。
因為很多平台的出版本很耗費時間，不利於頻繁地來回測試與驗證。
這時候我會建議一開始用同一個版本出各個目標平台。
例如(PC, iOS, Android)
然後以相似的測試條件錄製效能報告。
比對不同平台的測試報告，確認系統的瓶頸是不是大同小異
例如說各系統所佔的CPU比例在所有平台都差不多，只是絕對值的差別。
(PC 0.1ms，iOS 1ms之類的)
如果差不多，那可以先專注在PC改善就好。
如果有平台特別異常的項目，就要紀錄下來，納入改善的考量。
標準作業流程
首先大家要清楚知道在調整效能的時候是大家都需要幫忙的
但是瓶頸分析可以一個人做就好。
其他人依照分析的方向作改進會比較有效率。
所以這邊分享一下之前試過一次，
覺得不錯的一個作業流程 經過幾次的調整就可以有效率的達到目標)
1. 錄製多平台，每平台多個效能檔
2. 使用分析工具確認效能瓶頸沒有受到不同測試環境而有極大的差異
3. 列出應該調整的瓶頸項目
4. 詢問項目開發人員改進方案與難易度
5. 制訂改進目標
6. 分發工作項目
7. 著手進行改善
8. 回到步驟1驗收
項目1與2目的是避免只錄一次會有偏差，
我曾經遇過只對某一次測試結果分析，結果某個很貴的角色在該次測試沒出現
最後多花了時間處理這個角色。
項目3就比較偏向如何使用工具來找瓶頸，比較偏一些心得與技巧，
會在之後的文章介紹。
項目4,5,6,7 就是前面提到的項目，重點就是挑風險低，改善多的項目先下手。
結論
以上講了一些過去的心得與自己的觀念，
之後預計會介紹如何在UE4 Profile CPU，如何使用Unreal Frontend。
Blueprint(BP)轉C++的衡量，以及一些曾經遇過常常是瓶頸的項目。
不過我只列出大綱，時間都未訂就是了XD