2011-03-24 175 views
6

使用標準調試器調試性能問題幾乎是無望的,因爲細節級別過高。其他方式使用探查器,但他們很少給我提供良好的信息,特別是當涉及到GUI和後臺線程時,我不知道用戶是否真的在等待計算機,或者不知道。一種不同的方式是簡單地使用Control + C並查看代碼停止的位置。使用>>,>,> |,||,| <,<,<<,<<

我真正想要的是具有快進,播放,暫停和倒帶功能以及代碼的一些視覺表現。這意味着我可以設置代碼在Fast Forward上運行,直到我將GUI導航到關鍵點。然後,我將代碼設置爲以慢速模式運行,同時獲得一些視覺聲明,正在執行哪些行(可能是某種縮小的代碼視圖)。例如,我可以將執行速度設置爲0.0001x。我相信我會以這種方式獲得一個非常好的可視化,不管這個問題是在特定的模塊內還是在模塊之間的通信中。

這是存在嗎?我的具體需求是在Python中,但我會對以任何語言查看這些功能感興趣。

+2

調用'fire_all_employees()'或'system('rm -rf /')'後,'rewind'可能很難。但我喜歡一般的想法...... :) – sarnold 2011-03-24 09:23:34

+1

它只需要倒帶代碼執行的可視化。我喜歡自動解僱員工的想法,因爲這是一項非常乏味的任務。 ;) – David 2011-03-24 09:24:55

+1

所以你想要的東西類似於[Omniscient Debugger](http://www.lambdacs.com/debugger/),對吧? [TOD](http://pleiad.dcc.uchile.cl/tod/index.html)是另一個例子。不過,它們都是爲Java而設計的。 – 2011-03-24 09:28:43

回答

4

任何調試器中都存在「快進至臨界點」功能,它被稱爲「斷點」。確實有一些調試器可能會降低執行速度,但這不會幫助您調試性能問題,因爲它不會減慢計算機速度。處理器,磁盤和內存仍然與以前一樣緩慢,所發生的只是調試器在每行代碼之間插入延遲。這意味着每一行代碼突然或多或少地在同一時間,這意味着它隱藏了性能問題出現的任何痕跡。

找到性能問題的唯一方法是記錄在應用程序中完成的每個調用以及需要多長時間。這是一個分析器的功能。事實上,使用探查器是棘手的,但可能沒有更好的選擇。從理論上講,您可以記錄每次通話和每次通話的時間,然後播放後退和前進,但這會佔用大量的記憶,實際上它不會告訴您任何事情,除了探查器所做的事情事實上,它會告訴你更少,因爲它會錯過某些類型的性能問題)。

您應該可以通過探查器找出需要很長時間的問題。請注意,這可能是由於某些函數調用需要很長時間,因爲它們執行了大量處理,或者可能是需要很長時間的系統調用變得很慢(網絡/磁盤)變慢。或者可能是一個非常快速的呼叫被稱爲負載和負載的時間。分析器將幫助你弄清楚這一點。但是,如果您只需在關鍵部分打開Profiler(減少噪音),並且您可以多次運行該關鍵部分(提高準確性),它就會有所幫助。

+1

第3段,句子2和3,我同意(沒有太多其他的:-)我認爲唯一的配置文件很好的是1)對調用棧進行採樣(不僅僅是PC),2)可以在I/O和計算,3)逐行報告(不只是函數)包含行的樣本百分比(不是調用計數,不是時間測量,特別是不是「自我時間」(Grrr ...),以及4)您可以控制何時取樣。 [見此]。(http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343) – 2011-03-24 13:57:03

+0

@Mike:我絕對沒有聲明要使用哪種類型的探查器或它的功能,除了它應該能夠僅分析關鍵部分。所以你對某個特定分析器的要求並不違揹我所說的任何事情。 – 2011-03-24 14:54:21

+0

@lennart:對,你打開了剖析器的類型。這只是你說的「找到性能問題的唯一方法就是記錄應用程序中完成的每個調用以及花費多長時間,這是一個分析器的功能。」你不是一個人這麼想,這就是我認爲的人與人之間的解決他們的表現問題。 – 2011-03-24 15:01:40

1

我認爲應用程序執行過程中有一個階段需要花費很長時間 - 即讓您等待。 我想你真的想看看你可以改變,以使其更快。

有效的技術是random-pausing。 您在調試器下運行該應用程序,並在其執行的部分中讓您等待,暫停它並檢查調用堆棧。這樣做幾次。

這裏有一些方法可能會花費更多的時間,而不是必要的。

  • 你不知道和不真正需要的I/O。
  • 非常頻繁地分配和釋放對象。
  • 關於數據結構的失控通知。
  • 其他不勝枚舉...

不管它是什麼,當它發生時,調用堆棧的考試將證明這一點。 一旦你知道它是什麼,你可以找到一個更好的方法來做到這一點,或者根本就沒有做到。

如果程序需要5秒鐘時間可能需要1秒鐘,那麼您在每次暫停時將看到問題的概率爲4/5。事實上,如果你可以避免這樣做,任何你在多個堆棧樣本上看到的函數都會給你一個顯着的提速。 而且,幾乎所有可能的瓶頸都可以通過這種方式找到。

不要考慮函數時間或者它們被調用的次數。尋找經常出現在堆棧上的代碼行,你不需要。

示例添加:如果您取5個堆棧樣本,並且其中2個出現一行代碼,則它負責大約2/5 = 40%的時間,給予或帶走。你不知道確切的百分比,你不需要知道。 (技術上,平均來說它是(2 + 1)/(5 + 2)= 3/7 = 43%。還不錯,並且你確切知道它在哪裏)。

1

你正在描述的方法,並且許多評論似乎對理解性能影響的概率性嘗試相對較弱。對於GUI和其他空閒線程程序,Profiler確實很好地工作,儘管需要一些練習來閱讀它們。我認爲你最好的選擇就是在那裏 - 學會更好地使用profiler,這就是它的用途。

您描述的具體用途僅僅是附加探查器,但不記錄。將GUI導航到問題點。點擊分析器記錄按鈕,執行操作並停止錄製。查看結果。固定。再來一遍。

相關問題