[[327635]]

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

硬件、編譯器造成的

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

代碼編寫風格

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

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

void asd() {}  
int main() {  
    int i=0;  
    i++;  
    asd();　　//方便區分上下文  
    ii=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　　　　//ii=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也不需要重編譯。

未完待續

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