2009-01-23 91 views
5

我有一個基準測試應用程序來測試我寫了一些API的性能不同的表現。在這個基準測試應用程序中,我基本上使用QueryPerformanceCounter,並通過在調用API之後和之前將QPC值的差異除以頻率來獲得時間。但是基準測試結果似乎有所不同如果我從不同的驅動器運行應用程序(在同一套Dll上運行相同的可執行文件)。另外,在特定的驅動器上,第一次運行應用程序,關閉應用程序並重新運行它會產生不同的基準測試結果。誰能解釋這種行爲?我在這裏錯過了什麼嗎?運行託管應用程序第二次表現出了比第一次

一些更多有用信息:

的行爲是這樣的:運行該應用程序,關閉它,並重新運行它,在基準測試結果看來,以提高對第二次運行和以後保持不變。這種行爲在從C驅動器運行的情況下更爲突出。 我還想提一下,我的基準測試應用程序可以選擇重新運行/重新測試特定的API,而無需關閉應用程序。我確實知道存在着點擊事件,但我不明白的是,在第一次運行應用程序時,如果您多次重新運行API而未關閉應用程序,則在運行幾次後性能會穩定下來,然後關閉並重新運行同樣的考驗,表現似乎有所改善。

此外,如何做到從不同的驅動器上運行,當你考慮性能的變化?

[信息更新]

我做了一個NGEN現在不同的運行從同一位置消失之間的性能差異。即如果我打開基準測試應用程序,運行一次,關閉它並從同一位置重新運行它,它會顯示相同的值。

但現在我已經遇到的另一個問題。當我從D驅動器啓動應用程序並運行它幾次(在基準編程的同一次啓動中幾次API迭代),然後從第三次迭代開始,所有API的性能似乎下降了大約20% 。然後,如果關閉並重新啓動應用程序並運行它,對於前2次迭代,它會給出正確的值(與從C獲得的值相同),然後性能再次下降。從C驅動器運行時看不到此行爲。從C盤開始,無論你運行多少次運行,它都是非常一致的。

我使用大雙陣列來測試我的API的性能。我擔心GC會在測試之間進行,所以我在每次測試之前和之後明確地呼叫GC.Collect()& GC.WaitForPendingFinalizers()。所以我不認爲它與GC有任何關係。

我試着使用AQ時間知道什麼從3日開始迭代發生,但有趣的是,當我運行與AQ時間剖析它的應用程序,性能不倒的。

如不提出任何有趣的IO活動的性能計數器。

感謝 NIRANJAN

+0

科裏對一個可能的問題做出了正確的回答。但是,如果您可以詳細說明結果,則會有所幫助。例如,如果第二輪是WORSE,那麼這是一個不同的故事。 :) – BobbyShaftoe 2009-01-23 06:14:11

+0

道歉以前不描述。行爲如下: 運行應用程序,關閉它並重新運行一次,基準測試結果在第二次運行中似乎有所改善,此後保持不變。這種行爲在從C驅動器運行的情況下更爲突出。 – 2009-01-23 08:31:59

回答

1

我覺得這裏有效果的組合:

首先,每次運行相同的功能測試工具中多次,使用相同的數據,將有可能提高,因爲:

  • JIT編譯優化將是(由科裏福伊爲mentioned already)運行最頻繁的提高性能的代碼
  • 程序代碼會在磁盤緩存(如mentioned already由Crashwork)
  • 一些程序代碼將在CPU緩存如果它足夠小,執行頻率足夠高

如果數據不同的測試工具中的功能,每次運行,這可以解釋爲什麼關閉和運行測試工具再次改進了結果:數據現在將位於磁盤緩存中,這不是第一次。

最後,是的,即使兩個「驅動」是同一個物理磁盤上,他們將有不同的表現:可以讀取數據從盤片比內外部更快。如果它們是不同的物理磁盤,那麼性能差異似乎很可能。另外,一個磁盤可能比另一個磁盤碎片更多,導致更長的查找時間和更慢的數據傳輸速率。

3

是。它被稱爲Just-In-Time compiling。基本上,您的應用程序部署爲MSIL(Microsoft中間語言),並且在第一次運行時它會轉換爲本機代碼。

你總是可以運行NGEN(見上面的文章),或在你的性能測試腳本一個溫暖期在那裏通過實際情景基準業績之前運行了好幾次。

4

運行的應用程序帶來了從硬盤驅動器到操作系統的磁盤緩存(在RAM)的可執行文件和其他文件。如果之後很快再次運行,這些文件中的很多文件可能仍處於緩存中。 RAM比磁盤快得多。

當然還有一盤可能比另一個更快。

1

此外,其他因素可能開始發揮作用。機器上的文件系統緩存,最近使用的數據的緩衝等

最佳運行幾個測試(或幾百!)和整個組平均出來的,除非你是專門測量冷啓動時間。

相關問題