計時過程中的結果不一致

我試圖通過使用System.currentTimeMillis()（或者System.nanoTime()）來計算我的程序的性能，我注意到每次運行它時它都會給出不同的結果，完成任務。計時過程中的結果不一致

即使是簡單的測試：

long totalTime; 
long startTime; 
long endTime; 
startTime = System.currentTimeMillis(); 
for (int i = 0; i < 1000000000; i++) 
{ 
    for (int j = 0; j < 1000000000; j++) 
    { 
    } 
} 
endTime = System.currentTimeMillis(); 
totalTime = endTime-startTime; 
System.out.println("Time: " + totalTime);

產生各種不同的輸出，從0到200。任何人都可以說，我在做什麼錯誤或建議的替代解決方案？

來源

2012-03-22 comeonism

循環沒有做任何事情，所以你要計時多久才能檢測到循環是毫無意義的。

更準確地計時循環無助於您，您需要做一些稍微有用的工作來獲得可重複的結果。

如果您在32位窗口上運行，我建議您嘗試-server。

10億個時鐘週期大概需要10年時間，所以它並沒有真正迭代很多次。

來源

2012-03-22 21:11:36

+1對於計算，近似十年不會那麼糟糕。我計算了13年來的2.4GHz CPU，單線程。 – 2012-03-22 21:26:44

+1我認爲彼得正在大幅低估事物。我最近做了一些基準測試，現在JVM有一個即時優化器，可以快速發現你要檢查的數組元素，並填充__only__。我懷疑它與任何你可能嘗試和使用的隨機數發生器都是相互影響的。我也認爲它知道你是否正在看屏幕。祝你好運，試圖欺騙它做一些實際工作。 – RalphChapin 2012-03-22 21:27:38

原來我正在做的東西，我正在實施三種不同的貪婪算法（第一個適合，下一個適合和最適合）和時間他們的表現。問題是，有時候最適合的表現比其他表現更快，有時候第一次適合做這件事，它沒有任何意義（儘管這些算法的代碼看起來是正確的）。 – comeonism 2012-03-22 21:29:20

這正是預期的行爲 - 在重新運行計時時應該會變得更快。當你多次重新運行一個方法時，JIT會花費更多的精力將其編譯爲本地代碼並對其進行優化;我期望在運行此代碼足夠長的時間之後，JIT將完全消除該循環，因爲它實際上並沒有做任何事情。

在Java代碼上獲得精確基準測試的最好和最簡單的方法是使用類似Caliper這樣的工具來「加熱」JIT，以鼓勵它充分優化代碼。

來源

2012-03-22 21:12:02

計時過程中的結果不一致

回答

相關問題