2016-11-30 197 views
1

通常配置文件數據是,通過對運行程序的堆棧進行隨機抽樣以查看哪個函數正在執行,在運行期間內,可以統計確定哪些方法/函數調用最耗時,需要干預的瓶頸。如何描述打嗝的表現?

但是這與整體應用/遊戲性能有關。有時會發生在性能上存在單一和孤立的打嗝,無論如何都會造成可用性問題(用戶注意到它/引入的滯後於某些內部機制等)。通過幾秒鐘的執行定期分析是不可能知道的。即使打嗝的持續時間足夠長(說30毫秒,這還不夠),爲了檢測一些過於頻繁調用的方法,我們仍然會錯過許多其他方法的執行,這些方法由於隨機而被「跳過」採樣。

那麼是否有任何技術來描述打嗝,以便在修復這些「稀有瓶頸」之後保持幀率更穩定?我假設使用C#或C++等語言。

回答

1

這已經回答過了,但我不能找到它,所以這裏去...

的問題是並條機常規有時花費太長時間。 假設它通常少於1000/30 = 33毫秒,但偶爾需要超過33毫秒。

DrawFrame的開頭,設置一個定時器中斷,在40ms後過期。 然後在DrawFrame的末尾,禁用中斷。 所以如果它觸發,你知道DrawFrame是花了一個非常長的時間。

在中斷處理程序中放置一個斷點,並在它到達時檢查堆棧。 機會很大,你在做這件昂貴的事情的過程中已經發現了它。 這是random pausing的變體。

+0

假設時間消耗事件開始發生在33毫秒後.. 40毫秒後電子.. – GameDeveloper

+0

@DarioOO:並非它開始發生40毫秒後,但它仍然發生在40毫秒後。 –

+0

我們可能會有延遲,因爲通常發生在1-3毫秒之間的事情持續1到30毫秒(在幀的開始處)。我們完全錯過了這個方法(所以有33毫秒的中斷不可能發生) – GameDeveloper