軟體工程/測試/效能分析簡介
在軟體工程中，程式效能分析、軟體效能分析或簡稱效能分析，是一種動態程式分析（與靜態程式碼分析相對），透過收集程式執行過程中收集的資訊來調查程式的行為。這種分析的通常目的是確定程式的哪些部分需要最佳化——以提高其整體速度，減少其記憶體需求，或者有時兩者兼而有之。
- （程式碼）效能分析器是一種效能分析工具，最常見的是僅測量函式呼叫的頻率和持續時間，但除了更全面的效能分析器外，還有其他特定型別的效能分析器（例如記憶體效能分析器），能夠收集廣泛的效能資料。
- 指令集模擬器也——必然地——是一個性能分析器，可以測量程式從呼叫到終止的全部行為。
效能分析器使用各種各樣的技術來收集資料，包括硬體中斷、程式碼插裝、指令集模擬、作業系統鉤子和效能計數器。效能分析器的使用在效能工程過程中被“呼叫”。
程式分析工具對於理解程式行為極其重要。計算機架構師需要這樣的工具來評估程式在新架構上的執行情況。軟體編寫人員需要工具來分析他們的程式並識別關鍵程式碼部分。編譯器編寫人員經常使用此類工具來了解他們的指令排程或分支預測演算法的執行情況……（ATOM，PLDI，'94）
效能分析器的輸出可能是：
- 觀察到的事件的統計摘要（概要檔案）
- 摘要概要檔案資訊通常顯示在事件發生位置的原始碼語句上，因此測量資料的大小與程式的程式碼大小成線性關係。
/* ------------ source------------------------- count */ 0001 IF X = "A" 0055 0002 THEN DO 0003 ADD 1 to XCOUNT 0032 0004 ELSE 0005 IF X = "B" 0055
- 記錄事件的流（跟蹤）
- 對於順序程式，摘要概要檔案通常就足夠了，但是並行程式中的效能問題（等待訊息或同步問題）通常取決於事件的時間關係，因此需要完整的跟蹤才能瞭解正在發生的事情。
- （完整）跟蹤的大小與程式的指令路徑長度成線性關係，這使得它有些不切實際。因此，可以從程式中的一個點啟動跟蹤並在另一個點終止跟蹤以限制輸出。
- 與虛擬機器的持續互動（例如透過螢幕顯示進行持續或週期性監控）
- 這提供了在執行過程中的任何所需點切換跟蹤開啟或關閉的機會，以及檢視有關（仍在執行）程式的正在進行的指標。它還提供了在關鍵點暫停非同步程序以更詳細地檢查與其他並行程序的互動的機會。
效能分析工具存在於 1970 年代初的 IBM/360 和 IBM/370 平臺上，通常基於定時器中斷，這些中斷在設定的定時器間隔記錄程式狀態字 (PSW) 以檢測執行程式碼中的“熱點”。這是取樣（見下文）的早期示例。在 1974 年初，指令集模擬器允許進行完整的跟蹤和其他效能監控功能。
Unix 上的效能分析器驅動的程式分析可以追溯到至少 1979 年，當時 Unix 系統包含一個基本的工具“prof”，它列出了每個函式以及它使用了多少程式執行時間。1982 年，gprof 將該概念擴充套件到完整的呼叫圖分析[1]
1994 年，Digital Equipment Corporation 的 Amitabh Srivastava 和 Alan Eustace 發表了一篇論文，描述了 ATOM。[2]ATOM 是一個將程式轉換為其自身效能分析器的平臺。也就是說，在編譯時，它將程式碼插入到要分析的程式中。插入的程式碼輸出分析資料。這種修改程式以分析自身的技術被稱為“插裝”。
2004 年，gprof 和 ATOM 論文都出現在有史以來 50 篇最有影響力的 PLDI 論文列表中。[3]
扁平效能分析器根據呼叫計算平均呼叫時間，並且不根據被呼叫方或上下文細分呼叫時間。
呼叫圖效能分析器顯示函式的呼叫時間和頻率，以及基於被呼叫方的相關呼叫鏈。但是上下文沒有保留。
此處列出的程式語言具有基於事件的效能分析器
- Java：JVMTI（JVM 工具介面）API（以前稱為 JVMPI（JVM 效能分析介面））為效能分析器提供了掛鉤，用於捕獲諸如呼叫、類載入、解除安裝、執行緒進入離開等事件。
- .NET：可以將效能分析代理作為 COM 伺服器附加到 CLR。與 Java 類似，執行時隨後會提供各種回撥到代理中，用於捕獲諸如方法 JIT/進入/離開、物件建立等事件。特別強大之處在於效能分析代理可以以任意方式重寫目標應用程式的位元組碼。
- Python：Python 效能分析包括 profile 模組、hotshot（基於呼叫圖）以及使用“sys.setprofile”函式來捕獲諸如 c_{call,return,exception}、python_{call,return,exception} 等事件。
- Ruby：Ruby 也使用類似於 Python 的介面進行效能分析。存在 profile.rb、模組中的扁平效能分析器和 ruby-prof C 擴充套件。
一些效能分析器透過取樣來執行。取樣效能分析器使用作業系統中斷定期探測目標程式的程式計數器。取樣概要檔案通常在數值上不太準確和具體，但允許目標程式以接近全速執行。
得到的資料並非精確值，而是統計近似值。實際誤差通常大於一個取樣週期。事實上，如果某個值是取樣週期的n倍，則其預期誤差為n個取樣週期的平方根。[4]
在實踐中，取樣分析器通常可以比其他方法更準確地描繪目標程式的執行情況，因為它們對目標程式的侵入性較小，因此不會產生太多副作用（例如對記憶體快取或指令解碼管道的副作用）。此外，由於它們對執行速度的影響較小，因此可以檢測到否則會被隱藏的問題。它們也相對不容易過高地評估小型、頻繁呼叫的例程或“緊湊”迴圈的成本。它們可以顯示在使用者模式下花費的時間與可中斷核心模式（例如系統呼叫處理）下花費的時間的相對數量。
儘管如此，處理中斷的核心程式碼會導致輕微的CPU週期損失，快取使用被轉移，並且無法區分不可中斷核心程式碼中發生的各種任務（微秒級活動）。
專用硬體可以超越這一點：一些最近的MIPS處理器JTAG介面具有一個PCSAMPLE暫存器，它以一種真正無法檢測到的方式對程式計數器進行取樣。
一些最常用的統計分析器包括AMD CodeAnalyst、Apple Inc. Shark、gprof、Intel VTune和Parallel Amplifier（Intel Parallel Studio的一部分）。
一些分析器會插裝目標程式，新增額外的指令以收集所需的資訊。
插裝程式可能會導致程式效能發生變化，可能導致結果不準確和海森堡錯誤。插裝總會對程式執行產生一些影響，通常會使其變慢。但是，插裝可以非常具體，並且可以小心控制以使其影響最小。對特定程式的影響取決於插裝點的放置和用於捕獲跟蹤的機制。對跟蹤捕獲的硬體支援意味著，在某些目標上，插裝可以只在一個機器指令上。插裝的影響通常可以從結果中推斷出來（即透過減法消除）。
gprof是一個使用插裝和取樣的分析器示例。插裝用於收集呼叫者資訊，實際計時值透過統計取樣獲得。
- 手動：由程式設計師執行，例如，新增指令以顯式計算執行時間，簡單地計數事件或呼叫測量API，例如應用程式響應測量標準。
- 自動原始碼級：根據插裝策略，由自動工具新增到原始碼中的插裝。
- 編譯器輔助：例如，“gcc -pg …”用於gprof，“quantify g++ …”用於Quantify。
- 二進位制翻譯：工具將插裝新增到已編譯的二進位制檔案中。例如：ATOM。
- 執行時插裝：在執行之前直接對程式碼進行插裝。程式執行完全由工具監督和控制。例如：Pin、Valgrind。
- 執行時注入：比執行時插裝更輕量級。在執行時修改程式碼以跳轉到幫助函式。例如：DynInst。
- 直譯器除錯選項可以在直譯器遇到每個目標語句時啟用效能指標的收集。位元組碼、控制表或JIT直譯器是三個示例，它們通常完全控制目的碼的執行，從而能夠提供極其全面的資料收集機會。
- 管理程式：透過在管理程式下執行（通常）未修改的程式來收集資料。例如：SIMMON。
- 模擬器和管理程式：透過在指令集模擬器下執行未修改的程式，以互動方式和選擇方式收集資料。例如：SIMON（批處理互動式測試/除錯）和IBM OLIVER（CICS互動式測試/除錯）。
- Dunlavey，“使用從呼叫棧取樣派生的指令級成本進行效能調整”，ACM SIGPLAN通告42，8（2007年8月），第4-8頁。
- Dunlavey，“效能調整：全力以赴！”，Dr. Dobb's Journal，第18卷，第12期，1993年11月，第18-26頁。
- 文章“速度至上——消除效能瓶頸”介紹瞭如何使用IBM Rational Application Developer對Java應用程式進行執行時間分析。
- 使用VTune™效能分析器分析執行時生成和解釋的程式碼