如何分析和提高(C/C++)程式的編譯速度？

版權聲明：本文為部落客原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

本文鏈接：//www.cnblogs.com/lihuidashen/p/12935470.html

微信鏈接：//mp.weixin.qq.com/s/MFOaa-Dw1iNMXuXPfXjLBA

 

一個別人的vs 2010 的程式, 編譯, 載入數據, 運行, 需要個把小時。當改程式碼然後再運行的時候,又要個把小時才能編譯看結果.這樣豈不是很浪費時間, 怎麼辦？這樣如何修改程式,怎麼提高效率啊?

當我們遇到這樣情況的時候，是不是不知所措呢？怎麼防止遇到這樣的情況呢，我們來分析一下程式加速的一些方法。

硬體、編譯器造成的

使用好點的電腦無疑是一個操作上的最佳選擇，其次，對於編譯器也是可以編譯選項優化的，例如在VS環境中，可以通過配置屬性來實現，具體步驟如下，大家可以參考： * //blog.csdn.net/yizhou2010/article/details/52635288 *

程式碼編寫風格

多使用自加、自減指令和複合賦值表達式

你覺得使用i++ ,i = i + 1,i += 1有區別嗎？我們來測試一下 C程式碼：

void asd() {}
int main() {
    int i=0;
    i++;
    asd();　　//方便區分上下文
    i=i+1;
    asd();
    i+=1;
    return 0;
}

反彙編：

mov     [rbp+i], 0　　　　//i的初始化
add     [rbp+i], 1　　　　//i++;
call    _Z3asdv         ; asd(void)
add     [rbp+i], 1　　　　//i=i+1;
call    _Z3asdv         ; asd(void)
add     [rbp+i], 1　　　　//i+=1;

我們看到這個結果是一樣的，但是在更加複雜的表達式中就會多生成幾個指令了，而且用 i += 1 的，總是比寫 i = i + 1的要稍微那麼好看些。

除法換成乘法或者移位來表達

除法就是由乘法的過程逆推來的，依次減掉（如果x夠減的）y^(2^31),y^(2^30),…y^8,y^4,y^2,y^1。減掉相應數量的y就在結果加上相應的數量，一般來說，更耗時間一些，用一個demo來測試一下

auto time_start = std::chrono::system_clock::now();
int iCount = 100000;
double k ;
for (int i = 0; i < 1000000; i++)
{
     tmp = iCount / 2;
}
std::chrono::duration<double> time_spend = std::chrono::system_clock::now() - time_start;
double test1 = time_spend.count() * 1000;
cout<<"test1 cost "<<time_cost<<" ms"<<endl;

time_start = std::chrono::system_clock::now() ;
for (int i = 0; i < 1000000; i++)
{
     tmp = iCount * 0.5f;
}
time_spend = std::chrono::system_clock::now() - time_start;
test2 = time_spend.count() * 1000;
cout<<"test2 cost "<<time_cost<<" ms"<<endl;

time_start = std::chrono::system_clock::now() ;
for (int i = 0; i < 1000000; i++)
{
     tmp = iCount >>1;
}
time_spend = std::chrono::system_clock::now() - time_start;
test3 = time_spend.count() * 1000;
cout<<"test3 cost "<<time_cost<<" ms"<<endl;

我們輸出結果會發現，移位和乘法比除法要省3-5倍時間,移位相對而言是最省時間的。

多用直接初始化，少用拷貝初始化

string s1 = "hiya";    // 拷貝初始化
string s2("hello");    // 直接初始化
string s3(10, 'c');    // 直接初始化

當我們使用拷貝初始化時，我們要求編譯器將右側運算對象拷貝到正在創建的對象中，如果需要的話還要進行類型轉換，會浪費一定的資源時間，而直接初始化是要求編譯器使用普通的函數匹配來選擇與我們提供的參數最匹配的構造函數和拷貝構造函數。

我們來看看Primer中怎麼說的

當用於類類型對象時，初始化的複製形式和直接形式有所不同：直接初始化直接調用與實參匹配的構造函數，複製初始化總是調用複製構造函數。複製初始化首先使用指定構造函數創建一個臨時對象，然後用複製構造函數將那個臨時對象複製到正在創建的對象」

還有一段說到：

通常直接初始化和複製初始化僅在低級別優化上存在差異，然而，對於不支援複製的類型，或者使用非explicit構造函數的時候，它們有本質區別：

ifstream file1("filename")://ok:direct initialization
ifstream file2 = "filename";//error:copy constructor is private

局部變數、靜態局部變數、全局變數與靜態全局變數

  • 局部變數是存在於堆棧中的，對其空間的分配僅僅是修改一次esp暫存器的內容即可；
  • 靜態局部變數是定義在函數內部的，靜態局部變數定義時前面要加static關鍵字來標識，靜態局部變數所在的函數在多調用多次時，只有第一次才經歷變數定義和初始化；
  • 當一個文件或者數據反覆使用時，應該存儲在全局變數中，避免重複載入使用；
  • 靜態全局變數是靜態存儲方式，靜態全局變數則限制了其作用域，即只在定義該變數的源文件內有效，在同一源程式的其它源文件中不能使用它。

靜態變數是低效的，當一塊數據被反覆讀寫，其數據會留在CPU的一級快取（Cache）中

程式碼冗餘度

避免大的循環，循環中避免判斷語句

在寫程式過程中，最影響程式碼運行速度的往往都是循環語句，我記得當時在寫matlab的時候，處理大數據，都是禁止用循環的，特別是多層嵌套的循環語句。

其次，盡量將循環嵌套控制在 3 層以內，有研究數據表明，當循環嵌套超過 3 層，程式設計師對循環的理解能力會極大地降低。同時，這樣程式的執行效率也會很低。因此，如果程式碼循環嵌套超過 3 層，建議重新設計循環或將循環內的程式碼改寫成一個子函數。

for (i=0;i<100;i++)
{
    for (j=0;j<5;j++)
    {
       for (j=0;j<5;j++)
        {
            /*處理程式碼*/
        }  
    }
}

多重 for 循環中，如果有可能，應當盡量將最長的循環放在最內層，最短的循環放在最外層，以減少 CPU 跨切循環層的次數

for (i=0;i<100;i++)
{
    for (j=0;j<5;j++)
    {
            /*處理程式碼*/
    }
}

改為：

for (j=0;j<5;j++)
{
    for (i=0;i<100;i++)
    {
            /*處理程式碼*/
    }
}

邏輯判斷不要在循環中使用，當 for 循環的次數很大時，執行多餘的判斷不僅會消耗系統的資源，而且會打斷循環「流水線」作業，使得編譯器不能對循環進行優化處理，降低程式的執行效率

if (condition)
{
    for (i = 0;i < n;i++)
    {
        /*處理程式碼*/
    }
}
else
{
    for (i = 0;i < n;i++)
    {
        /*處理程式碼*/
    }
}

盡量避免遞歸，遞歸就是不停的調用自身，所以非常消耗資源，甚至造成堆棧溢出和程式崩潰等等問題！

int Func(int n)
{
if(n < 2)
return 1;
else
return n*Func(n-1);
}

因此，掌握循環優化的各種實用技術是提高程式效率的利器，也是一個高水平程式必須具備的基本功。

盡量不使用繼承和多重繼承

多重繼承增加了類的繼承層次的複雜性，調試難度增加當然風險也增加了，而且使用父類指針指向子類對象變成了一件複雜的事情，得用到C++中提供的dynamic_cast來執行強制轉換。但是dynamic_cast是在運行期間而非編譯期間進行轉換的，因此會會帶來一些輕微的性能損失，建議類型轉換盡量採用c++內置的類型轉換函數，而不要強行轉換

少用模板，因為模板是編譯期技術，大量採用模板也會增加編譯時間

在c++primer3中，有一句話：

在多個文件之間編譯相同的函數模板定義增加了不必要的編譯時間 簡單點說，對於一個zhidaovector的函數，比如size()，如果在不同的cpp中出現，在這些文件編譯的時候都要把vector::size()編譯一遍。然後在鏈接的時候把重複的函數去掉,很顯然增加了編譯時間。模版函數需要在編譯的時候實例化zhidao,所以呢,不把模版的實現程式碼放到頭文件中的話(在頭文件中實例化),那麼每個使用到這個模版的cpp的都要把這個模版重新實例化一遍,所以增加了編內譯時間

編碼依賴性

聲明與實現分離，刪除不必要的#include

  • 使用include時，只需要include這個介面頭文件就好
  • 並不是所有的文件都需要包含頭文件 iostream，定義了輸出函數引用就好
  • ostream頭文件也不要，替換為 iosfwd, 為什麼，參數和返回類型只要前向聲明(forward declared )就可以編譯通過

盡量減少參數傳遞，多用引用來傳遞參數。

bool func1(string s1,  string s2)
bool func2(string *s1, string *s2)
bool func3(string &s1, string &s2)

指針和引用都不會創建新的對象，函數func2和func3不需要調用析構和構造函數，函數func1使用值傳遞在參數傳遞和函數返回時，需要調用string的構造函數和析構函數兩次。

適當的採用PIMPL模式

很實用的一種基礎模式，通過一個私有的成員指針，將指針所指向的類的內部實現數據進行隱藏。 將實現放到CPP里，主要作用在於編譯分離，其實是增加了編碼量以及初次編譯時長，增量編譯才體現作用。 例如：指針的大小為（64位）或32（8位），X發生變化，指針大小卻不會改變，文件c.h也不需要重編譯。

未完待續

方法還有很多，比如使用多執行緒，多任務並行編譯，分散式編譯，預編譯等等，另外，在編譯大型項目時，分散式編譯更優，往往能夠大幅度提升性能

推薦閱讀

（點擊標題可跳轉閱讀）

【編程之美】用C語言實現狀態機(實用)

【編程之美】超時重傳，滑動窗口，可靠性傳輸原理

【編程之美】論嵌入式架構的重要性

Tags:

VirMach 便宜 VPS

QNews

QNews