CPU 效能分析與改善 (一) 觀念篇
主旨 筆者過去被指派多次改善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%。 這是經驗談，就算是有經驗的老手也會中招。 畢竟一個遊戲系統很大，每個人都會知道自己經手的系統哪裡效能不佳。 如果直接分配一段時間(例如一週)，讓每個人改善自己的系統效能。 這種作法是最浪費，最沒有效率的，因為效率瓶頸可能根本就不在某人上。 又例如說某個系統有一段寫法很暴力或是用了很多層迴圈， 花了大把時間去改善，結果這段程式碼只執行一次，也不會影響畫面卡頓。 那麼這個時間應該要省下來去作別的項目。 藉由量測效能估算極限 先從量測效能開始的另一個好處是可以很快知道極限在哪裏。 拿到效能數據，有經