性能分析

不合標準的應用程式性能會產生軟體或網路問題。為確保軟體滿足或超過設計的期望值，有必要分析應用程式的性能以發現潛在的問題。這個過程被稱為“性能分析”。它包括檢查應用程式以確保每個組件有效地工作，並根據設計密切注視處理器的使用、網路和系統服務、存儲和輸入/輸出(I/O)。

基本介紹

• 中文名：性能分析
• 環節：使應用程式的組件可見
• 影響：不合標準應用程式會產生軟體問題
• 結果：可以診斷潛在的性能問題

歷史

早在1970年代，IBM System/360及IBM System/370的平台就有性能分析工具，一般是用計時器中斷在固定的時間紀錄程式狀態字（PSW）來偵測程式運行時的“過熱點”（hot spots）。這是早期使用抽樣方式進行性能分析的示例之一。在1974年時，指令集仿真器就允許完整的事件蹤跡，以及其他性能監控的機能。

以性能分析工具為主的UNIX程式分析至少可以回溯到1979年，當時Unix系統有一個基礎工具prof，可以列出每一個函式，也列出此函式總共花了多少時間。1982年時gprof工具延伸此概念，可以列出完整的函式調用圖。

1994年時，迪吉多的Amitabh Srivastava和Alan Eustace提出了描述ATOM的論文。ATOM是一個平台，可以將程式配合其性能分析工具調整，在編譯期間，ATOM會在要分析的程式中加入代碼，而加入的代碼會輸出分析數據，這種修改程式，輸出自身份析數據的技術，稱為邏輯注入。

2004年時．gprof和ATOM論文都出現在前50個最具影響力的程式語言設計和實現會議（PLDI）論文中。

診斷問題

性能分析的一個必不可少的環節是使應用程式的組件可見。當能夠了解組件是如何互動時，就可以診斷潛在的性能問題。傳統上，了解分散式應用程式中組件間的互動一直很困難。而VisualStudioAnalyzer提供了不同的方法來了解互動情況，從而解決了此問題。例如，可在進程間或這些互動的持續時間內了解互動情況。當能夠深入了解應用程式並發現出現問題的原因時，就可以：

●確保應用程式的行為按設計如期進行。

●通過詳細報告應用程式和網路回響以及傳遞的時間，顯示應用程式在哪些方面導致大量的處理開銷、檔案爭用或磁碟或網路訪問過度延遲。

●收集全面的分析數據並將其結合用於應用程式進程的端對端視圖和數據涉及的所有設備。

以輸出方式分類

一般性能分析器

一般性能分析器（flat profiler）根據函式調用計算平均的函式調用次數，而且不會根據被調用函式或是運行脈絡（context）細分函式調用次數。

函式調用圖性能分析器

函式調用圖會顯示函式被調用的次數及頻率，也會列出函式調用鏈（call-chains），有些軟體會列完整的調用鏈，有些不會。

以分析方式的分類

性能分析器本身也是程式，可以在被分析程式運行時收集相關信息，來分析該程式。根據收集到信息的細微度，以及收集信息的方式，可以分為事件為基礎的性能分析器，或是統計式的性能分析器。有些性能分析器為了收集信息，會中斷程式的運行，因此在時間量測上有一定的解析度限制。

事件為基礎的性能分析器

以下列出的程式語言有事件為基礎的性能分析器：

• Java：JVMTI（JVM工具接口）API，以前稱為JVMPI（JVM性能分析接口），提供給性能分析器的hook，可以抓到像函式調用、類別載入、卸載、執行緒的進入及離開等事件。
• .NET框架：利用性能分析的API，可以連線到像是COM伺服器的性能分析代理器（profiling agent）。像Java一様，在運行會提供許多回調函式給代理器，可以捕捉到像是方法JIT/進入/離開，對象創建及其他。特別的是性能分析代理器可以用任意方式改寫目的應用程式的位元組碼。
• Python：Python的性能分析包括profile模組，以調用函式圖為基礎的hotshot，以及用'sys.setprofile'函式來捕捉像c_{call,return,exception}及python_{call,return,exception}的事件。
• Ruby：Ruby也用類似Python的性能分析界面。目前有在profile.rb中的一般性能分析器及相關模組。

統計式的性能分析器

有些性能分析器是用取様的方式運作。取様式的性能分析器利用作業系統的中斷，在固定時間取様目的程式的程式計數器。取様式的性能分析器在數值上較不精準，但對目的程式運行時間的影響最小，允許目的程式可以在接近全速的速度下運作。

所得到的數據不是精準值，只是統計上的近似值而已。“實際誤差的量一般會大於一個取樣時間．若芋某一數值是取様時間的n倍，其誤差約為n倍取様時間的平方根”

在實務上統計式的性能分析器會比其他的分析方式更能知道目的程式各部分占的比例，而且相較之下有較少的邊際效應（例如存儲器快取或是指令解碼的管道線等），由於統計式的性能分析器對程式運行速度的影響較小．因此可以偵測到一些其他方式偵測不到的問題。這種方式可以看出用戶模式及可中斷系統模式（例如系統調用）分別占的時間。

不過由於系統程式需處理中斷，仍然會花一些CPU的運行周期，分散快取的讀取，而且無法分辨在不可中斷核心模式下的行為。

有些特製的硬體可以克服這類的問題：有些最近MIPS微理器中，JTAG接口有一個PCSAMPLE暫存器，可以用一種無法偵測到的方式來取様程式計數器。

最常用的統計式的性能分析器包括AMD的CodeAnalyst、蘋果公司的Shark（OSX）、Intel的VTune及Parallel Amplifier（Intel Parallel Studio的一部分）。

插裝型的性能分析器

有些性能分析可以用插裝（也稱為邏輯注入）的方式處理目的程式，也就是在目的程式中加入額外指令來收集需要的信息。

程式的插裝會影響程式的性能，可能會出現不精確的結果及heisenbug（捉摸不定，不易重現的bug）。插裝一定會對程式運行有些影響，常見的情形是使程式變慢。不過插裝可以特定只針對部分程式，而且可以小心控制以使影響降到最低。其對於特定程式的影響是看插裝放置的位置，以及捕捉蹤跡（trace）的機制。有些處理器有硬體支持可以捕捉蹤跡，插裝可以只占一個機器語言周期的時間。一般可以從結果中移除插裝的影響。

gprof是一個同時用插裝及取様的性能分析器的例子。插裝用來獲取被調用函式的信息，而實際花的時間則是由取様方式來獲得。

插裝是決定性能分析器可控制程度及時間解析度的關鍵。以下是一些方式的分類。

• 手動：是由程式設計者加入指令，在運行時計算相關信息，例如計算事件或是調用像是應用程式回響測試（ARM）標準的API。
• 原始碼層級自動處理：依照插裝政策，利用自動化工具自動在原始碼中加入instrumentation，像Parasoft公司的Insure++。
• 中間語言：在彙編語言或是bytecode中加入針對多種高級語言的instrumentation，，例如OpenPATOpenPAT。
• 編譯器協助：像gprof和Quantify都是這類的例子，像用gcc -pg ...可以使用gprof，用quantify g++ ...可以使用Quantify。
• 二進制翻譯：此工具在編譯好的可執行檔中加入instrumentation，例如ATOM。
• 運行時插裝：代碼直接在運行前修改，工具可以完成的監控及控制程式的運行，例如用Pin、Valgrind、DynamoRIO。
• 運行時注入：修改程度比運行時插裝要小，代碼在運行時修改，令加入跳躍到協助用函式的指令，例如和DynInst。

解釋器式的插裝

• 解釋器式除錯選項，可以在解釋器處理每個目的指令時，收集性能量度的相關信息。像位元組碼、控制表及JIT的解釋器都在目標代碼運行時有完整的控制能力，因此有機會收集到非常全面的數據。

hypervisor或仿真器

• Hypervisor：在hypervisor下運行（一般而言）沒有修改的程式，可以收集相關信息，例如SIMMON工具。
• 仿真器及hypervisor：在指令集模擬器運行（一般而言）沒有修改的程式，可以互動式及選擇性的收集相關信息，例如SIMON及OLIVER工具。