效能分析往往是開發人員容易忽視的步驟，這也是為什麼我們一年一年的不停做效能優化的原因，大部分人對嵌入式的實時性和效能要求沒有概念。 visual studio實際上提供了效能分析工具(tools\performancetools\performance wizard),其中有兩種分析方法:sampling和instrumentation,即抽樣和**注入，抽樣的原理比較簡單，kprofile也類似，就是用比較短的週期去採用pc指標，看看是在哪個函式在執行，並把當前週期的時長累計為該函式的執行時長； **注入，相當於打點，是將檢測的**加入到每個函式中。
開發出的軟體不僅僅是可以使用，還有一點重要的影響陰虛是軟體的效能。軟體效能是軟體的一種非功能特性，它關注的不是軟體是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。由於感受軟體效能的主體是人，不同的人對於同樣的軟體能有不同的主觀感受，而且不同的人對於軟體效能關心的視角也不同。由於目前網路應用非常普遍。記得老師曾講過乙個關於12306**開發最初版本的根本買不到票的問題，這便是乙個直觀的案例。當只有一兩個人使用時，軟體可以執行的很流暢，但當成前上萬的人同時購票，系統每開闢乙個程序就需要讓後面的程序排隊等待，這樣所產生的等待時間就會很長，這就暴露出了軟體效能低下的問題，可以說這樣的軟體，能夠使用，但是因為效能原因不得不進行新一輪公升級。
現階段我們的程式設計可能都只專注於能不能用而忽略了演算法的時間和空間複雜度這兩大重要影響因素，這樣是不可取的。
《構建之法》讀後感 二
構建之法 這本書是很長時間以來讀到的第一本能夠吸引我的專業書。草草讀完整本書，我發現 構建之法 的作者文筆十分幽默風趣，書中把很多專業名詞或者專業知識用十分通俗的語言表達出來，甚至我們可以在書中看到很多對話形式的文字，通過這些對話，我們可以學到很多專業知識。相比於市面上很多其他專業書，這是唯一一本能...
《構建之法》讀後感二
構建之法 二 這一章提到的 規範，我們編寫 時要注重 風格規範和 設計規範，無論是類名，物件名，縮排還是行寬什麼的，在結對子程式設計時都要有所規定，不然到後面出現的類或是物件多了，就很容易混亂，分不清楚誰是誰。要學會封裝，編寫函式，將功能模組具體化，減少主方法裡面的 避免大規模的出錯。除此之外，複審...
構建之法讀後感二
我知道了乙個合格的工程師在開發時需要同時考慮質量和效率，與之同時需要具備的技能包括 單元測試 效能分析 個人研發流程 psp 並且學到了單元測試，即讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質量能得到穩定的 量化的保證 單元測試應該測試程式中最基本的單元 如在c c...