2012-04-29 50 views
0

我有一個輔助功能,可以完成一些相當昂貴的操作。gettimeofday/settimeofday使功能看起來不佔用時間

我想剖析算法的主要部分,但是這個輔助函數被調用了很多。因此,測量時間考慮到輔助功能的時間。

爲了解決這個問題,我決定設置和恢復時間,使輔助功能看起來是瞬間的。我定義了以下宏:

#define TIME_SAVE struct timeval _time_tv; gettimeofday(&_time_tv,NULL); 
#define TIME_RESTORE settimeofday(&_time_tv,NULL); 

。 。 。並將它們用作輔助功能的第一行和最後一行。不過,由於某些原因,輔助功能的開銷仍然包含在內!因此,我知道這是一種混亂的解決方案,所以我後來繼續前進,但我仍然好奇爲什麼這個想法不起作用。 有人可以解釋爲什麼嗎?

+1

使用分析器。 – orlp 2012-04-29 06:14:44

+0

剩下的時間如何測量? – talonmies 2012-04-29 06:23:03

回答

0

有一些可能發生的可能性。一個是,Linux試圖保持時鐘的準確性,對時鐘的調整可能會「平滑」或以其他方式「修正」,以便在系統內保持時間平滑感。如果您正在運行NTP,它也會嘗試保持合理的時間。

我的方法是不修改時鐘,而是跟蹤每個過程部分消耗的時間。對昂貴部分的調用將通過積累(通過獲取進入和退出時的gettimeofday與積累時間之間的差異)並從總時間中減去。我敢肯定,還有其他的可能性,更奇特的方法。

4

如果你堅持這樣分析,不要設置系統時鐘。如果您有權這樣做,這將打破各種各樣的事情。基本上你應該忘記你曾聽說過settimeofday。你想要做的是在要從測量中排除的功能之前和之後調用gettimeofday,並計算差異。然後,您可以從總時間中排除在此功能中花費的時間。因爲gettimeofday很可能(1)比你想要測量的要花費大量的時間,並且(2)可能涉及過渡到內核空間,這會對你的程序的緩存一致性造成嚴重的損害。第二個問題是,在嘗試觀察程序的性能特徵時,實際上改變它們是最有問題的。

你真的應該做的是忘記了這種分析的(gettimeofday甚至gcc的-pg/gmon分析),而使用oprofileperf或類似的東西。這些現代分析技術基於週期性地對指令指針和堆棧信息進行統計採樣而工作;你的程序自己的代碼根本就沒有被修改過,所以它的行爲儘可能接近它沒有運行探查器的行爲。

+0

現在,'gettimeofday()'通常可以在不轉換到內核空間的情況下處理(作爲「vsyscall」)。 – caf 2012-04-29 11:20:45

+0

@caf:我知道可以做的唯一系統是Linux/x86_64。據我所知,在Linux下的所有其他操作系統和所有其他cpu arch都需要系統調用。 – 2012-04-29 15:36:30