用於c ++代碼的分析器，非常困

Question

我是剖析新手。 我想優化我的代碼以滿足時序約束。 我使用Visual C ++ 08 Express，因此必須下載一個分析器，對我來說它非常困。 我做了一些搜索，但沒有找到關於Sleepy的正確教程，我的問題是：如何正確使用它？ 我掌握了分析的一般概念，所以我按照％排序來排序以找到我的瓶頸。 首先，在這個列表的頂部，我有ZwWaitForSingleObject ， RtlEnterCriticalSection ， operator new ， RtlLeaveCriticalSection ， printf ，一些迭代器......並且在它們占用了60％之后出現了我的第一個函數，第一個位置是Child Calls。 有人可以解釋一下為什么上面提到的，它們是什么意思，如果我無法訪問這個關鍵的60％，我怎樣才能優化我的代碼？ （對於“源文件”：未知......）。 另外，對於我的函數，我認為每行都有時間，但事實並非如此，例如算術或某些函數沒有時間（不嵌套在未使用的“if”子句中）。 最后一件事：如何發現某條線可以執行超高速，但被稱為數千次，是實際的瓶頸？

最后，睡眠好嗎？ 或者我平台的一些免費替代品？

非常感謝！ 干杯！

• • • • 更新 - - - - -

我找到了另一個版本的探測器，名為plain Sleepy。 它顯示了一些片段被調用的次數加上行的數量（我猜它指向關鍵的片段）。 所以在我的情況下.. KiFastSystemCallRet需要50％ ！ 這意味着它等待一些數據嗎？ 如何改善這個問題，是否有一個可行的方法來跟蹤導致這些多次調用的原因並最終刪除/更改它？

Answer 1

我想優化我的代碼以滿足時序約束

你在這個行業中遇到了一個持久的問題。 您希望找到使代碼花費更少時間的方法，並且您（和許多人）假設（並且已經教過）唯一的方法是通過進行各種測量。

有一個少數人的觀點，它唯一需要推薦的是實際的重要結果 （ 加上背后的鐵定理論 ）。

如果你有一個“瓶頸”（你做了，可能是幾個），它需要一些時間，比如30％。
只是將其視為一個可以找到的bug 。

使用暫停按鈕隨機停止程序，仔細查看程序正在執行的操作以及執行操作的原因。 詢問是否可以擺脫它。 這樣做10次。 平均而言，您會看到3個暫停的問題。 如果不是真的有必要，你不止一次看到的任何活動都是速度錯誤。 這並不能准確地告訴您問題的成本，但它確實能夠准確地告訴您問題是什么，並且值得修復。 你會看到沒有探查者可以找到的東西，因為探查者只是程序，不能對構成機會的東西持寬容態度。

有些人厭惡風險，認為它可能無法提供足夠的加速比值。 當然，收益率很低的可能性很小，但這就像投資一樣。 該理論平均說它是值得的，並且也有很小的機會獲得高回報。 在任何情況下，如果您擔心風險，更多的樣本將解決您的恐懼。

解決問題之后，剩下的每個瓶頸都會占用更大的百分比，因為它們並沒有變得更小，但總體程序確實如此。 因此，當您重復整個過程時，它們將更容易找到。

有很多關於剖析的文獻，但實際上說它在實踐中實現了多少加速。 這是一個具有近3個數量級加速的具體示例 。

Answer 2

我使用GlowCode（商業產品，類似於Sleepy）來分析本機C ++代碼。 您運行檢測過程，然后執行程序，然后查看該工具生成的數據。 儀表步驟在每個方法的入口點和出口點處注入一點跟蹤功能，並簡單地測量每個功能運行完成所需的時間。

使用調用圖分析工具，我列出了從“最常用時間”到“最少使用時間”的方法，該工具還顯示了呼叫計數。 只需鑽進最高百分比的例程，就可以看出哪些方法使用的時間最多。 我可以看到一些方法非常慢，但鑽進它們我發現它們正在等待用戶輸入或服務響應。 有些人花了很長時間，因為他們每次調用時都會調用幾次內部例程。 我們發現有人犯了編碼錯誤，並且為列表中的每個項目重復走一個大的鏈表，當他們真的只需要走一次。

如果按“最常調用”排序為“最少調用”，則可以看到從任何地方調用的一些微小函數（迭代器方法如next()等）。要檢查的東西是確保函數被稱為最常見的是非常干凈。 在一個名為500次的例程中保存一毫秒以繪制一個屏幕將使該屏幕加速半秒。 這有助於您確定哪些是最重要的工作場所。

我已經看到了兩種使用分析的常用方法。 一種是進行一些“通用”分析，運行一系列“正常”操作，並發現哪些方法最大程度地降低了應用程序的速度。 另一種是進行特定的分析，重點關注特定用戶對性能的抱怨，並通過這些功能來揭示他們的問題。

我要提醒您的一件事是將您的更改限制為可能會對用戶體驗或系統吞吐量產生重大影響的更改。 將鼠標點擊一毫秒的剃須對平均用戶沒有影響，因為人類的反應時間並不那么快。 賽車手的反應時間在8毫秒范圍內，一些優秀的抽搐游戲玩家甚至更快，但像銀行出納員這樣的普通用戶的反應時間將在20-30毫秒范圍內。 好處可以忽略不計。

進行20個1毫秒的改進或者一個20毫秒的改進將使系統響應更快。 如果你可以通過許多小的改進做出單一的重大改進，那就更便宜，更好。

同樣，每秒處理100個用戶的服務削減一毫秒將使性能提高10％，這意味着您可以改進服務以處理每秒110個用戶。

值得關注的是，嚴格地編碼更改以提高性能通常會增加復雜性，從而對代碼的結構產生負面影響。 假設您決定通過緩存結果來改進對數據庫的調用。 你怎么知道緩存何時失效？ 你是否添加了緩存清理機制？ 考慮一個金融交易，其中循環所有訂單項以產生運行總計很慢，因此您決定保持runningTotal累加器更快地回答。 您現在必須修改各種情況的runningTotal，如線條空白，反轉，刪除，修改，數量更改等。它使代碼更復雜，更容易出錯。