【紙上得來終覺淺】
最近開始看這本書，站在巨人的肩膀上，希望有更大的收穫！！
一個程序的執行效率是取決於改程序翻譯成彙編語言之後的執行的機器指令的條數。而每一個機器指令的執行的週期是一定的。C語言和C++都是高於彙編語言的高級語言，其中，C語言源代碼與其相應的機器指不是完全同一的，但是大致是線性的，但是C++語言的源代碼與編譯代碼的開銷變化很大的。一條C++指令可能對應於3條彙編指令，而另外的一條可能對應300條。正因爲這樣，很多時候我們寫出來的代碼本身就是低效的，這不能全然怪罪於C++語言本身，那麼真正的軟件的低效又體現在什麼地方呢?
設計的效率 ----> 算法與數據結構，程序分解
軟件性能---->
編碼的效率 ----> 語言結構，系統體系結構 ， 庫，編譯器優化
總得來說，軟件的效率是由設計的效率以及編碼的效率來決定的，其中，設計的效率關乎程序的高層設計，也就是說你要有把握全局的能力，在很大的程度上，這與語言本身並沒有關係，無論再怎麼高效的語言都彌補不了糟糕的全局設計。
提到全局設計，數據結構與算法的設計是不得不提的。算法與數據結構的最優化設計絕對是軟件性能的必要條件。其次，程序分解，則是指整個程序分解爲幾個不同的模塊，模塊之間的交互，以及各個模塊的設計。
在完成了上述這些必要的設計之後，編碼的效率便提上日程了，語言的結構便是語言本身的結構產生的一些開銷對程序性能的影響。系統的體系結構，不考慮體系結構的開發是無用的。現實世界沒有無限的內存，無限的計算能力，並行的線程執行，想當然的代碼註定是會爛掉的。因此，我們必須銘記於心的是“內存不是無限大的”，“內存訪問開銷並不是均衡的，對於不同的存儲介質的訪問時間是有着數量級的差別的”，“我們的程序沒有專門的CPU”，“在一臺單處理器的計算機上，並行的程序只能是輪詢的”。第三點，便是庫的選擇，庫函數的實現是奔着重用性的，這其中對於性能必定有所折中，因此在面對性能嚴苛的代碼段時，自己實現也未嘗不可。最後，是編譯器的問題了，編譯器的優化技術也是影響程序性能的點。但是絕對要記住，不要依賴編譯器的優化，而寫出低效的代碼，應該儘量不依賴編譯器的優化。
上述幾個因素，是影響程序性能的點，同時也是立志編寫出高效的代碼的編程人員應該時刻謹記的。
今天讀完導言，收益頗豐，很快就可以開始讀這本書了，期待C++帶給我的更多的驚喜！！！