現在我們假設您已經縮小了應用中典型瓶頸的位置。對於你所知道的，它可能是你運行重新索引你的表的批處理過程;它可能是SQL查詢運行在有效日期的樹上;它可能是幾百個複合對象的XML編組。換句話說，你可能有這樣的事情：對於您複雜的算法，您如何衡量其性能？
public Result takeAnAnnoyingLongTime(Input in) {
// impl of above
}
不幸的是，你已經確定你的瓶頸，甚至後，所有你能做的就是芯片不停。沒有簡單的解決方案可用。
你如何衡量瓶頸的性能，以便你知道你的修復方向是朝着正確的方向發展的？
我會使用相同的工具衡量他們/，讓我的方法來找到他們首先。
即，堅持時間安排和日誌記錄呼籲各地。如果數字開始下降，那麼你可能會做正確的事情。
正如msdn column中提到的那樣，將性能調整與塗裝金門大橋的工作進行比較：一旦完成繪畫整個事情，現在是時候回到開始並重新開始。
兩點：
小心臭名昭著的 「優化空閒循環」 的問題。 （例如，在「保時捷停車場」標題下看到optimization story）。也就是說，僅僅因爲例行程序花費了大量時間（如您的分析所示），請不要認爲它是負責任的對於用戶感知的緩慢性能。
最大的性能提升往往不是來自於對算法實現的巧妙調整或優化，而是因爲認識到完全有更好的算法。一些改進相對明顯，而其他改進則需要對算法進行更詳細的分析，並可能對所涉及的數據結構進行重大改變。這可能包括將處理器時間換成I/O時間，在這種情況下，您需要確保您沒有隻優化其中一種措施。
回到所問的問題，確保你測量的任何東西都代表了用戶的實際體驗，否則你的努力可能完全浪費時間。
這是一個有趣的問題。我不認爲有人知道答案。我相信問題的重要部分是對於更復雜的程序，沒有人能預測它們的複雜性。因此，即使您擁有分析器結果，也應該根據對程序所做的更改來解釋它，這非常複雜，因爲您沒有理想的解決方案。
我認爲這是我們擁有如此臃腫的軟件的原因。我們只進行優化，以便在我們的快速機器上運行相當簡單的案例。但是一旦你把這些碎片放到一個大的系統中，或者你使用了更大量的輸入，使用了錯誤的算法（直到那時在理論上和實際上都看不見）纔會開始顯示它們真正的複雜性。
示例：您將創建一個處理Unicode的字符串類。您可以在計算機生成的XML處理的地方使用它，但這並不重要。但是Unicode處理就在那裏，佔用了部分資源。本身，字符串類可以非常快，但稱它爲百萬次，程序將會很慢。
我相信目前軟件的大部分膨脹都屬於這種性質。有一種方法可以減少它，但它與OOP相矛盾。關於各種技術，有一本有趣的書There is an interesting book，它是面向內存的，但其中大多數可以恢復到更快的速度。
我想確定兩件事：
1）它有多複雜？最簡單的方法是繪製輸入的時間經文大小。 2）它是如何綁定的？是內存，還是磁盤，還是帶有其他進程或機器的工控機，或者是其他進程或機器，或者是其它進程或機器，或者是其他進程或機器的IPC，或者是..
現在點（2）更易於解決和解釋：如果有更多的RAM或更快的機器，更快的磁盤或移動到演出以太網等。如果你發現自己的痛苦，那麼你可以在硬件上投入一些資金以使其可以忍受。
這不是一個難題。你需要了解的第一件事是測量性能不是你如何發現性能問題。瞭解速度有多慢並不能幫助你找出原因。你需要一個診斷工具，並且是一個好的工具。我有很多經驗，this是最好的方法。它不是自動的，但它圍繞大多數輪廓儀運行。