7

我有一個Windows Forms應用程序,它有2個線程。這些線程相互之間具有零交互,第一個線程運行時不會與第二個線程混淆。他們之間沒有同步,因爲沒有必要發生這種情況。第一個線程處理應用程序的UI,改變顏色和標籤,並且有一個定時器運行,以捕獲這個定時器每200毫秒觸發的一些用戶輸入。第二個線程更多地涉及並持續運行其編碼,直到用戶退出應用程序關閉。Visual Studio C#2010 Express調試運行速度比Release快更多

第二個線程首先從內存中讀取並將數據存儲到List中,然後使用這些數據進行一些計算。我有一個StopWatch類定時器來測量完成第二個線程的迭代所需的時間。該定時器被重置,並在線程的一開始就啓動,然後一旦線程完成一次迭代就停止並打印到控制檯。這是我得到我的表現數據的地方。我一直允許線程運行至少1000次迭代,然後排除第一次運行的平均值。

構建的DEBUG版本,即由VSHOST運行的構建,或者在Visual Studio C#2010 Express中運行F5的構建。 Timings的平均值爲0.00035s,即0.35ms。

當應用程序在VSHOST外部運行時,可以通過按Ctrl-F5或通過從命中BUILD時產生的.exe運行應用程序。我也用REBUILD來測試這個絕對零變化。時間平均在365秒365秒。發佈版本的速度大約慢了1000倍。

我完全喪失了正在發生的事情。什麼是VSHOST這樣做可以讓程序運行得這麼快。我已經確保所有的變量初始化都是正確的。這就是說,我不知道爲什麼會發生這樣的事情。任何有關爲什麼我得到這樣的表演Dip的見解?

作爲一個側面說明我正在使用的計算機是64位具有超線程,16千兆字節RAM和雙HD6750的四核i7。所以它似乎不是一個線程太多的問題,這裏可能存在的唯一問題就是超線程。

以我的應用程序的形式提供的一段代碼。然而,由於內存地址讀取是發生減速的地方,因此無法提供工作代碼。

namespace Test Snippet 
{ 
public struct Data 
{ 
    public float X; 
    public float Y; 
    public float Z; 
    public float dX; 
    public float dY; 

    public Data(int c) 
    { 
     this.X = ReadFloat(Base + 0x50 + (c * 0x10)); 
     this.Y = ReadFloat(Base + 0x50 + (c * 0x10)); 
     this.Z = ReadFloat(Base + 0x50 + (c * 0x10)); 
     if (this.Z == 1) 
     { 
      targetindex = c; 
     } 
     this.dX = 0; 
     this.dY = 0; 
    } 
} 
class Class1 
{ 
    public int Base = new int(); 
    public List<Data> data = new List<Data>(); 
    public int targetindex = new int(); 
    public Data targetdata = new Data(); 

    public void GetData() 
    { 
     while (true) 
     { 
      data.Clear(); 
      for (int c = 0; c < 64; c++) 
      { 
       Data tempdata = new Data(); 
       teampdata = new Data(c); 
       data.Add(tempdata); 
      } 
      if (data.Count != 0) 
      { 
       targetdata = data[targetindex]; 
       data.RemoveAt(targetindex); 
       targetdata.dX = ReadFloat(Base + 0x66); 
       targetdata.dY = ReadFloat(Base + 0x65); 
       Data[] tempdatarray = new Data[data.Count]; 
       for (int j = 0; j < tempdatarray.Length; j++) 
       { 
        tempdatarray[j].dX = (float)Math.Acos(targetdata.dX * 10); 
        tempdatarray[j].dY = (float)Math.Acos(targetdata.dY * 10); 
       } 
      } 

     } 
    } 
} 

}

編輯::我曾嘗試相同的程序,但沒有使用線程。我有我用來捕獲用戶輸入的定時器調用的線程函數。我得到了同樣的結果。這意味着線程似乎不是問題。我還在另一臺計算機上完成了測試,出於某種原因,我沒有獲得巨大的差異。這導致我相信我的計算機可能有問題,或者由於其超線程能力而導致我的處理器如何處理線程。任何人都知道,超線程是否會導致多線程應用程序出現問題,而該應用程序並未在程序中明確使用它。說實話,我不知道如何設置。

+2

您是否嘗試使用真正的性能分析工具來分析應用程序? –

+0

對於一個經過深入研究,寫得很好的問題+1 +1 – MikeKulls

+0

很難提供沒有任何代碼的建議來測試。 –

回答

1

我沒有看到任何內容可以說你正在選擇發佈版本。這是工具欄上的一個選項。如果你直接運行一個調試版本,也許它正在尋找它找不到的東西。

編輯:除了我錯過的標題!!!! :-)

+0

這實際上是一個有趣的一點......我不是確定它是否會對問題的結論產生影響,但正如@MikeKulls所說的那樣,**你確定你正在運行發行版和可能優化的程序集版本嗎?** – fernandoespinosa

+0

另一點:假設以上不是問題,您的Debug配置和Release配置是否具有相同的平臺目標? – fernandoespinosa

+0

是的,我已經通過.csproj文件查看過,並確保發佈和調試都是相同的平臺。至於我正在使用哪種配置,我特別重建了每次運行的項目,並打開配置好的配置後的配置。我甚至嘗試使用發佈。作爲一個旁註,我也運行了Debug版本,而不是Host進程,Ala將在調試過程中進行處理並取消選中使用主機進程。與發佈版本的結果相同。這導致我相信這與主機進程有關。 – Nomad101

0

該問題與超線程無關。我無法找到鏈接,但2004年英特爾就這種工作方式(沒有任何營銷炒作)提供了很好的技術描述。但缺點是:核心0可能是一個真正的核心,核心1可能是一個與核心0共享相同硬件的邏輯核心。對於我們的觀點(應用開發者),核心0和核心1是真實的,而我們不不得不關心核心1是一個邏輯核心的事實(除了顯而易見的,邏輯核心只提供了大致13-30%的性能提升,這在技術描述中也有提到)。 Windows在真正的和邏輯的內核中調度線程做得相當不錯。您只需創建兩個線程,Windows就可以在覈心0和1上運行一個線程。您可以在BIOS中禁用HyperThreading,以編程方式爲您的線程設置處理器關聯,或者在任務管理器中設置關聯去體驗。

這就是說,嘗試使用超線程技術並不能幫助您解決問題。你應該像上面提到的那樣做,並且分析發佈版本。還要在事件日誌中尋找奇怪的錯誤。運行sysinternal的Process Explorer來查看在I/O中花費了多少時間。誰知道,也許發佈版本在某種程度上觸發了這臺機器上的設備驅動程序的一些古怪的行爲。

編輯:這裏是英特爾的技術說明(耶維基百科),實際上是從2002年:http://download.intel.com/technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf

1

因此,首先,你應該做一些性能分析。無論是使用分析工具,還是使用計時器在某處顯示某些消息,顯示某些事情需要花費多長時間 - 這應該允許您至少確定哪些代碼行緩慢運行,即使它沒有告訴您爲什麼它的運行在調試器下慢得多。沒有這些信息,你只能猜測。

現在,到了猜測...

我認爲這個問題有事情做與使用控制檯,基於這些觀察

  • 寫入控制檯窗口本身實際上是相對慢 - 你可以在運行一個將大量內容寫入控制檯的應用程序時看到這一點。如果保持窗口打開,則需要很長時間才能運行,但是如果最小化控制檯窗口,相同的操作可以更快地運行批次
  • 據我所知,你每寫0.35ms就向控制檯寫1條消息。這是一個lot的消息。
  • 根據您運行應用程序的方式,Visual Studio實際上在調試時將控制檯輸出重定向到Visual Studo內部的「輸出」窗口。

我的猜測是,在Visual Studio中的控制檯窗口比不進行調試時使用的等效機制更快了很多,並且附加放緩的原因實際上是你的日誌代碼。嘗試取出基於控制檯的日誌記錄並登錄到文件,以查看它是否有任何區別,或者甚至只是減少登錄消息的次數,例如記錄完成100次迭代所需的時間 - 這將減少控制檯對性能的影響(如果有的話)。

相關問題