一個別人的vs 2010 的程式, 編譯, 加載資料, 運行, 需要個把小時。當改代碼然后再運行的時候,又要個把小時才能編譯看結果.這樣豈不是很浪費時間, 怎么辦？這樣如何修改程式,怎么提高效率啊?
當我們遇到這樣情況的時候，是不是不知所措呢？怎么防止遇到這樣的情況呢，我們來分析一下程式加速的一些方法。
硬體、編譯器造成的
使用好點的電腦無疑是一個操作上的最佳選擇，其次，對于編譯器也是可以編譯選項優化的，例如在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(); //方便區分背景關系
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也不需要重編譯。
方法還有很多
方法還有很多，比如使用多執行緒，企鵝交流3524659088，多任務并行編譯，分布式編譯，預編譯等等，另外，在編譯大型專案時，分布式編譯更優，往往能夠大幅度提升性能。
uj5u.com熱心網友回復：
不完全型別可以提高編譯速度。就是頭檔案都不相互參考，而是用指標型別定義變數。可參考Qt.uj5u.com熱心網友回復：
這個情況首先考慮程式包回圈參考導致反復編譯，做工程要考慮包之間的依賴關系，避免反復參考。其次可以打開預編譯頭檔案選項，加速編譯uj5u.com熱心網友回復：
樓主說了好多，但除了硬體和編譯器會影響編譯速度，代碼撰寫什么的，比如乘除法、大回圈、遞回、繼承等演算法只會影響運行速度，并不會影響編譯速度。而硬體和編譯器恰好就是程式員無法輕易優化的基礎資源，如果提高？uj5u.com熱心網友回復：
c++的源檔案之間沒有明確的參考關系是編譯慢的一個重要原因，不像Delphi、Java、C#這些在源檔案中有明確的參考鏈（uses、import、using）使用預編譯頭能明顯縮短編譯時間，但是對于大專案來說總的編譯時間還是比較慢的，Delphi組的前設計師Allen Bauer 在google負責chrome專案時就抱怨說c++編譯太慢了，在20核40執行緒的E5上build一次也要幾小時~~~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/8077.html
標籤：基礎類