2013-03-27 100 views
1

我正在對程序進行一些評估測試,以測試執行時間以及檢查原始系統執行情況的跟蹤程序如何影響原始系統的性能。跟蹤程序不是會干擾系統,除了接收跟蹤消息之外,它們之間不會進行通信。Erlang程序跟蹤速度更快

到目前爲止的結果是,沒有跟蹤開啓的程序的平均值爲953.14微秒,而跟蹤開啓時爲937微秒。時間使用statistics(wall_clock)函數計算。

我的想法是,因爲我有一個來自跟蹤器的額外進程,而跟蹤機制需要他們自己的處理能力,所以它會減慢系統速度而不是加快速度。有什麼已知的原因爲什麼會發生這種情況?

回答

1

您是否曾經運行一次或幾次?當你使用wall_clock時,你會在這個測量中包含潛在的環境干擾,等待消息...,並且你不評估CPU時間。下面的例子示出了它:

1> F = fun() -> receive _ -> ok after 5000 -> timout end end. 
#Fun<erl_eval.20.111823515> 
2> F(). 
timout 
3> statistics(wall_clock),F(),statistics(wall_clock).  
{965829,5016} 
4> 

函數F顯然並不需要5秒的CPU時間,而是僅等待5秒。

這意味着您應該多次測量一次,一般不要使用第一次執行時間,這可能包括加載模塊代碼所需的時間,並且需要照顧環境 - 運行在其他進程上的另一個進程同一臺機器,並確保所測量的時間不是等待狀態的結果。

如果您使用運行時而不是wall_clock,您應該會看到所需的CPU時間,因此跟蹤代碼時會增加時間。請注意,使用多核可能會隱藏時間的增加。

+0

我跑了9次爲每個設置的措施,問題與這9次的平均時間有關。你是否建議我使用'runtime'而不是'wall_clock'?我正在多核系統上運行這項措施。 – aseychell 2013-03-27 11:40:43

+0

使用運行時,您將獲得運行代碼的每個核心活動的總和。使用此選項,您應該瞭解跟蹤選項成本。正如我在答案中所說的那樣,您將獲得的額外成本將至少部分地被多核系統上的併發執行所隱藏。 – Pascal 2013-03-27 14:18:13