調試期間的Visual Studio 2010代碼分析

Question

我正在VS2010 Professional中開發Visio插件，並在調試應用程序時尋找熱點（特別是在COM對象周圍）。 我發現了許多可以對現有.NET應用程序進行概要分析的概要分析器，但是（我所看到的）都不支持調試。 此外，由於這是.NET加載項，而不是完整的獨立可執行文件，所以我不確定它們是否公平。

我研究過的探查器：

1. EQATEC
2. Slimtune
3. CLR
4. nprof
5. VS2010 Performance Profiler-請注意，在我使用Professional時，此版本需要Ultimate或Premium。

有沒有人發現可以在VS2010調試會話期間使用的探查器？

Answer 1

我在SO上已經指出了這一點，其他人也是如此。

如果您的目標是提高性能（按時鍾時間衡量），那么到目前為止，最好的工具就是調試器本身及其“暫停”按鈕。 讓我告訴你為什么。

首先，讓我們看一個好的分析器

在分析器中，ANTS可能和它們一樣好。 當我在應用程序上運行它時，屏幕頂部看起來像這樣：

請注意，您必須選擇要查看的時間跨度，並且必須選擇要查看CPU時間還是文件I / O時間。 在該時間段內，您將看到以下內容：

試圖僅考慮CPU時間來顯示ANTS認為的“熱路徑”。 當然，它強調包含性的“與孩子在一起的時間（％）”，這很好。 在這樣的大型代碼庫中，請注意自拍時間“時間（％）”有多小？ 這很典型，您會明白為什么。

這就是說，您當然應該忽略包含率低的函數，因為即使您可以將它們減少為無操作，您在該時間間隔內的總時間將減少不超過包含率的百分比。

因此，您要查看包含率很高的函數，然后嘗試在其中查找某些內容以使它們花費更少的時間，通常是通過以下兩種方式：a）減少對子函數的調用，或b）調用函數本身減。

如果找到並修復它，則可以提高一定的速度。 然后，您可以再試一次。 當您找不到任何要修復的內容時，您就宣布勝利並把分析器放了一天。

請注意，您可能已經解決了其他問題，以提高速度，但是如果探查器沒有幫助您找到它們，則您假定它們不存在。 這些可能是真正的沉睡者。

現在讓我們來一些手動樣本

在困擾我的階段，我只是將應用程序隨機暫停了六次，因為它讓我等待。 每次我把調用棧的快照，我花了好長時間看程序做什么，它為什么這樣做。 其中三個樣本如下所示：

外部代碼
Core.Types.ResourceString.getStringFromResourceFile第506行
Core.Types.ResourceString.getText第423行
Core.Types.ResourceString.ToString第299行
外部代碼
Core.Types.ResourceString.getStringFromResourceFile第528行
Core.Types.ResourceString.getText第423行
Core.Types.ResourceString.ToString第299行
Core.Types.ResourceString.implicit運算符字符串404行
SplashForm.plugin開始第149行
Services.Plugins.PluginService.includePlugin行737
Services.Plugins.PluginService.loadPluginList第1015行
Services.Plugins.PluginService.loadPluginManifests第1074行
Services.Plugins.PluginService.DoStart第95行
Core.Services.ServiceBase.Start第36行
Core.Services.ServiceManager.start服務行1452
Core.Services.ServiceManager.startService行1438
Core.Services.ServiceManager.loadServices第1328行
Core.Services.ServiceManager.Initialize行346
Core.Services.ServiceManager.Start第298行
AppStart.Start第95行
AppStart。主線42

這是它在做什么。 它正在讀取資源文件（即I / O，因此查看CPU時間不會看到它）。 它正在讀取它的原因是獲取插件的名稱。 插件名稱在資源文件中的原因是將來可能需要對該字符串進行國際化。 無論如何，要獲取它的原因是可以在加載插件期間在初始屏幕上顯示該名稱。 大概的原因是，如果用戶想知道花費了這么長時間，則啟動屏幕將向他們顯示正在發生的事情。

這六個示例證明，如果未顯示名稱，或者顯示名稱但以某種更有效的方式獲得名稱，則該應用程序的啟動速度將大約提高一倍 。

我希望您能看到沒有任何能夠通過顯示測量結果而起作用的探查器能夠如此迅速地產生這種見解。

即使探查器顯示的是時鍾時間（而不是CPU）的百分比，它仍然會讓用戶試圖弄清楚發生了什么，因為在匯總例程中的時間時，它幾乎失去了所有說明性的內容如果必要的話 。

僅查看摘要統計信息和代碼時，人類的傾向是說“我可以看到它在做什么，但是我看不到有什么方法可以改進它。”

那么“統計意義”呢？

我一直都聽到這個消息，它來自天真的關於統計的信息。

如果六個樣本中有三個樣本顯示出問題，則表示該問題最有可能使用的實際百分比為3/6 = 50％。 這也意味着，如果您多次執行此操作，則平均成本為（3 + 1）/（6 + 2），也就是50％。 如果您節省50％的時間，那將使速度提高2倍。 成本可能會低至20％，在這種情況下，加速將僅為1.25倍。 成本可能高達80％的可能性均等，在這種情況下，加速將是5倍（！）。 是的，這是一場賭博。 加速可能小於估計，但不會為零，並且同樣可能非常大。

如果需要更高的精度，則可以獲取更多的樣本，但是如果犧牲了通過檢查樣本來獲得統計精度的見識，則可能找不到加速比。

PS 此鏈接顯示發現所有問題的關鍵重要性-不遺漏任何問題。

Answer 2

在VS2010中擴展管理器中進行挖掘之后，我發現了dotTrace 。 這樣就可以在調試過程中附加到正在運行的進程（在我的情況下為Visio）。

該工具的10天試用版提供了幫助，但是在400美元的價格下，它仍然感覺有些陡峭。 我仍然希望找到一種更便宜的方法來完成相同的任務。