大多數開發人員通常都有這個觀點，即組合語言和 c 語言適合用來編寫對效能要求非常高的程式。而 c++ 語言的主要應用範圍是編寫複雜度非常高的程式，但是對效能要求不是那麼嚴格的程式。但是事實往往並非如此，很多時候，乙個程式的速度在框架設計完成時大致已經確定了，而並非是因為採用了c++語言才使其速度沒有達到預期的目標。因此當乙個程式的效能需要提高時，首先需要做的是用效能檢測工具對其執行的時間分布進行乙個準確的測量，找出關鍵路徑和真正的瓶頸所在，然後針對瓶頸進行分析和優化，而不是一味盲目地將效能低劣歸咎於所採用的語言。事實上，如果框架設計不做修改，即使用c語言或者組合語言重新改寫，也並不能保證提高總體效能。
因此當遇到效能問題時，首先檢查和反思程式的總體框架。然後用效能檢測工具對其實際執行做準確地測量，再針對瓶頸進行分析和優化，這才是正確的思路。
但不可否認的是，確實有一些操作或者c++的一些語言特性比其他因素更容易成為程式的瓶頸，一般公認的有如下因素。
（1）缺頁：如第四章中所述，缺頁往往意味著需要訪問外部儲存。因為外部儲存訪問相對於訪問記憶體或者**執行，有數量級的差別。因此只要有可能，應該盡量想辦法減少缺頁。
（2）從堆中動態申請和釋放記憶體：如c語言中的malloc/free和c++語言中的new/delete操作非常耗時，因此要盡可能優先考慮從執行緒棧中獲得記憶體。優先考慮棧而減少從動態堆中申請記憶體，不僅僅是因為在堆中開闢記憶體比在棧中要慢很多，而且還與"儘量減少缺頁"這一宗旨有關。當執行程式時，當前棧幀空間所在的記憶體頁肯定在物理記憶體中，因此程式**對其中變數的訪問不會引起缺頁；相反，從堆中生成的物件，只有指向它的指標在棧上，物件本身卻是在堆中。堆一般來說不可能都在物理記憶體中，而且因為堆分配記憶體的特性，即使兩個相鄰生成的物件，也很有可能在堆記憶體位置上相隔很遠。因此當訪問這兩個物件時，雖然分別指向它們指標都在棧上，但是通過這兩個指標引用它們時，很有可能會引起兩次"缺頁"。
（3）複雜物件的建立和銷毀：這往往是乙個層次相當深的遞迴呼叫，因為乙個物件的建立往往只需要一條語句，看似很簡單。另外，編譯器生成的臨時物件因為在程式的源**中看不到，更是不容易察覺，因此尤其值得警惕和關注。本章中專門有兩節分別講解物件的構造和析構，以及臨時物件。
（4）函式呼叫：因為函式呼叫有固定的額外開銷，因此當函式體的**量相對較少，且該函式被非常頻繁地呼叫時，函式呼叫時的固定額外開銷容易成為不必要的開銷。 c語言的巨集和c++語言的內聯函式都是為了在保持函式呼叫的模組化特徵基礎上消除函式呼叫的固定額外開銷而引入的，因為巨集在提供效能優勢的同時也給開發和除錯帶來了不便。在c++中更多提倡的是使用內聯函式，本章會有一節專門講解內聯函式。
影響hashMap效能的因素
首 先算得key得hashcode值，然後跟陣列的長度 1做一次 與 運算 看上去很簡單，其實比較有玄機。比如陣列的長度是2的4次方，那麼hashcode就會和2的4次方 1做 與 運算。很多人都有這個疑問，為什麼hashmap的陣列初始化大小都是2的次方大小時，hashmap 的效率最高，我以2的...
影響軟體效能的因素
軟體效能是軟體的一種非功能特性，它關注的不是軟體是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。由於感受軟體效能的主體是人，不同的人對於同樣的軟體能有不同的主觀感受，而且不同的人對於軟體效能關心的視角也不同。目前，大部分系統都是為多使用者 跨地域 多部門機構提供服務的，目前一般中小企業的...
影響MySql效能的因素
哪些資料不適合存在資料庫中？流水佇列資料 一些系統中，每次交易，存放等都會產生流水佇列資料，資料量非常龐大 那些資料存放在cache 快取 中？減少資料庫的互動次數 在這裡我們列舉乙個n 1的問題，總所周知，在使用mybatis的時候當a物件中包含b物件 也就是乙個物件存在乙個關聯物件 a物件列表中...