程式碼執行速度和什麼有關
當我們遇到這樣情況的時候，是不是不知所措呢？怎麼防止遇到這樣的情況呢，我們來分析一下程式加速的一些方法。
硬體、編譯器造成的
使用好點的電腦無疑是一個操作上的最佳選擇，其次，對於編譯器也是可以編譯選項最佳化的，例如在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 我們輸出結果會發現，移位和乘法比除法要省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；elsereturn 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也不需要重編譯。 方法還有很多 方法還有很多，比如使用多執行緒，多工並行編譯，分散式編譯，預編譯等等，另外，在編譯大型專案時，分散式編譯更優，往往能夠大幅度提升效能。 宣告：本文系網路轉載，版權歸原作者所有。 更多幹貨內容只需要你關注電子芯吧客微信公眾號