c編譯時間優化

Ⅰ 提高c語言代碼效率

C語言7種提高效率

1、位運算替代乘除

位運算是C語言中的最小數據單元，移位運算或位處理基本上是每個MCU或者處理器的指令集中直接支持的所以C代碼編譯成匯編以後基本上簡單的幾條匯編指令即可完成運算。

然而對於乘除法CPU一般無法直接運行，當然現在高端的晶元一般支持FPU等等之類的處理，相對而言速度得到了顯著提升;但是大部分還是會比移位運算處理耗時，特別是有些編譯器直接把乘除法編譯成函數調用來處理。所以像n/8這樣的處理直接使用n>>3即可替代，這樣效率會更高。

2、變數的使用

使用全局變數相對局部變數效率更高，函數的局部變數一般處於函數內部，在調用過程中存在入棧與出棧野孝的情況，這樣就增加了函數調用的耗時，而全局變數直接訪問效率更高。當然全局變數是程序中要非常小心使用的，濫用全局變數的行為確實會增加系統各模塊之間的耦合，所以在程席中要規范全局的統一介面使用。

同時對於變數類型的使用也是大家需要注意的，數據類型不是越大越好，比如uint64_t的處理匯編生成代碼就相對比較多，執行效率一般比短數據類型要低，盡量選擇晶元相同位數的數據類型處理，當然大部分更小的數據長度也是合適的。

3、指針替代數組

相對數組索引，指針運算效率更快，數組是一片連續的內存空間，那麼通過指針移動進行數組數據的索引也是合適的。

比如我們遍歷數組array[i]，任意一次的循環都需要對其進行下 「i」值的標記與計算，而當指針「p」位於array數組位置的時候，循環僅只需要對「p」進行增量的操作，這樣指針耗時會比數組訪問小很多。

4、演算法優化

一些數據的處理明明可以通過更加簡潔的演算法，可是沒脊侍大部分程序員非要以最傻瓜的方式進行運算，最容易理解的就是高斯求和，1~100累加，還是選擇高斯求和演算法，當然還有很多演算法有多種形式，各有優劣，根據自身需求進行合理選擇。特別是一些應用根本沒有必要用使用高精度耗時的數據處理演算法，選擇一些低精度快速的演算法更加合適。

5、優化分支語句

我們都知道if-else語句是最常用的分支語句，其特點就是逐一判斷，既然是判斷就會消耗時間，然而對於一些處理並不是每個分支都是均勻執行的，如果你把頻繁執行的相應分支放到後面，勢必就需要執行較多前面的逐一判斷，從而降低代碼執行效率。

所以我們要對各個分支的執行頻率進行評估，把最有可能執行的放在判斷語句前面執行。同樣對於分支語句多級嵌套的情況，我們需要把頻率性對較高的放到外層，頻率低的放內層，這樣減枯吵少不必要的外層判斷。

6、循環語句的優化

在系統的多重循環過程中，需要程序員將最長的循環內容設置在系統的最內層，同時需要將最短的循環內容設置在系統的最外層。

這樣，能夠有效提升CPU的運行效率，減少循環次數。另外，如果在系統的循環過程中需要進行邏輯判斷，且循環的次數相對較大，就需要將循環判斷從系統內部轉移到系統的外部。

7、無敵」 宏"的利用

宏在C語言中是靈活度非常高的語法特性，宏代碼片段的使用其代碼表現形式上與函數差異並不是很大，大夥有學習C++語言模板的經驗，應該會覺得兩者有頗多相似之處。

在對函數進行調用的過程中，需要通過棧對其進行儲存，而且CPU在函數調用的過程中還要做好對數據的恢復准備，有效進行出棧和進棧的操作。所以佔用CPU時間除了代碼本身之外，對函數進行調用也需要佔據一定的時間。而宏就能節省參數壓棧、返回參數、C語言call調用以及執行return的操作步驟，從而提高程序的運行效率。

Ⅱ Xcode 構建速度優化（一）衡量編譯時間

隨著項目不斷迭代，工程文件越來越多，引用的三方庫也越來越多，這些直接導致編譯時間的不斷增加，完整編譯一次項目動輒需要五分鍾以上時間，實在有些影響開發效率，是時候來一波提速了。

為編譯和構建提速，首先我們需要對速度有一個衡量標准：准確獲得構建用時

首先，我們需要定義要衡量和優化的內容。 有兩種選擇：

xcode默認情況下會跟蹤所有構建，我們可以通過更改xcode相關設置，來在活動查看器中顯示出構建時間，通過命令行：

每次編譯成功後，會在Successed之後顯示出所用時間:

Xcode Build Timing Summary是Xcode10中加入的用於查看獲取構建時間和發現用時瓶頸方面的最有利工具。 可以通過Proct->Perform Action->Build With Timing Summary來開啟：這樣在 Build Log 的末尾就會添加 Timing Summary Log。我們可以通過這個 log 看到哪個階段是耗時的，便於我們進行優化。

如上圖中: xib階段的編譯耗時明顯是比普通c文件要多的，意味著我們可以通過減少xib方式來優化提升速度
而c文件的編譯用時比總時間還要長，是因為c文件是並行編譯的

在命令行中同樣可以開啟這個功能：

常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。

BuildTimeAnalyzer可以統計可以得出某個文件的類型檢查時長，每個表達式的類型檢查時長。

xcode-build-times-rendering是一個Ruby編寫的第三方工具，可以方便地分別測量目標的構建時間並在圖表上顯示它們，使用gem安裝

接下來使用這個工具自帶命令配置項目

然後構建項目並生成報告：

這個工具使用上比較簡單，缺點是只能從宏觀上生成各個target編譯的整體圖標，無法詳細列出各個內部編譯明細

XCLogParser可以詳細列出各個Target和內部每個文件的編譯耗時，對我們分析編譯時間瓶頸非常有幫助，它的工作原理主要是做為解析器，通過解析xcode編譯生成的xcactivitylog日誌來記錄
安裝：

編譯項目後，進行安裝

安裝成功後通過命令：

會自動在當前目錄的 build/xclogparser/reports/ 路徑下生成報告，其中--project參數需要設置為待分析項目的名字，並注意當前在終端切換到希望寫入日誌的目錄。

報告截圖：

這個工具將作為我們後面分析提升編譯構建速度的主要使用工具。

經過我多次在不同時間段，不同電腦上不斷嘗試編譯，
我發現編譯耗時是一個比較玄的東西，及時在同一台電腦，同一個項目， 同一套環境配置下，編譯用時也會隨著電腦當前狀態（包括同時打開進程、散熱等等）上下大幅跳動，就像演算法時間復雜度一樣，有時候我們明明做了一些細微的優化，但是結果反而是編譯耗時增加了，這是很正常的事情
所以，衡量這個標准需要我們取多次試驗中的平均值作為參考。