談到優化的問題，首先要明白C++的特性帶來多大的性能開銷、生成程序的瓶頸在哪個部分，然後採取針對性的措施。有時，在程序還沒有得到優化、真正地滿足需要之前，我們還不能鬆一口氣，對自己說“Code Complete！”
分別簡單地回顧一下：
1，C++對象模型
程序使用內存區、全局/靜態存儲區及常量數據區、堆和棧、C++中的對象
對象的生命週期、內存佈局、構造與析構的調用
2，C++語言特性的性能分析
繼承和虛函數：它們帶來的開銷，以及如何在必要的時候採取替代方案[1]
臨時對象
內聯函數
3，常用數據結構的性能分析
遍歷、排序、查找、刪除、插入：這些內容在稍微深入一點的C++書籍中，往往會有介紹。
動態數組的實現及分析：我想這部分除了明白原理以外，還需要在實際環境中進行實驗了。
4，操作系統的內存管理
windows內存管理：虛擬內存、訪問虛擬內存時的處理流程、地址映射、進程工作集[2]。
linux內存管理：同windows，當然，也需要測試。
5，動態內存管理
new、delete、內存泄露、智能指針
6，內存池[3]
原理示例、實現示例[4]。
7，動態鏈接庫與動態庫
windows DLL、linux DSO[5]
8，程序啓動過程
windows、linux程序啓動過程原理[6]
影響程序啓動性能的因素：源代碼、動態鏈接庫、配置文件/資源文件因素
9，程序啓動性能優化
10，內存分析工具IBM Rational Purify
11，性能分析工具IBM Rational Quantify
12，實時IO檢測工具FileMon
[1] 回憶MFC框架的實現——用函數指針表代替虛函數。
[2] 在這方面，yathing使用得還比較少，不夠深入，所以不清楚到底這類操作有多麼耗時——需要實際測試。
[3] “池”的概念，不僅僅用在內存管理中，類似的還有數據庫連接池、網絡訪問連接池等等。當創建、銷燬一個object非常頻繁的時候，我們就應該考慮通過“池”的“重利用”特性，減少開銷了。
[4] 實現“池”機制，究竟能夠多大地提高程序的性能呢？這不僅有趣，而且有實踐指導意義。值得詳細研究呢。
[5] DSO：Dynamic Shared Object
[6] 雖然我們不能修改操作系統的啓動過程（MS可不會公開內核源代碼呢~.~），這還真是令人沮喪。linux的內核也許會好一點？此外，我們將來可能遇到的還不止這些：J2EE中的容器執行效率、C++中間件的效率......只要存在“先加載後執行”，就會存在瓶頸的問題；廣義一點說：只要構成應用程序的部件之間還是“有縫狀態”，沒有達到“天衣無縫、親密無間”的情況，我們就會想到“瓶頸”的問題。