2011-06-14 50 views
1

當使用System.Diagnostics命名空間從服務器讀取應用程序日誌時,我遇到了一個有趣的問題。我正在讀取約16,000個條目到另一個文件供以後使用。例如:加速EventLogEntry.Message

string logType = "Application"; 

EventLog ev = new EventLog(logType, "server name"); 
int LastLogToShow = ev.Entries.Count; 
if (LastLogToShow <= 0) 
Console.WriteLine("No Event Logs in the Log :" + logType); 

int i; 
for (i = LastLogToShow - 1; i>= 0 ; i--) 
{ 
    EventLogEntry CurrentEntry = ev.Entries[i]; 
    Console.WriteLine("Event ID : " + CurrentEntry.EventID); 
    Console.WriteLine("Entry Type : " + CurrentEntry.EntryType.ToString()); 
    Console.WriteLine("Message : " + CurrentEntry.Message + "\n"); 
} 
ev.Close(); 

似乎一切都很好,直到我嘗試編寫CurrentEntry.Message。在這一點上,整個日誌從一秒鐘左右的時間裏跑到每100個參賽者佔用一秒鐘。有沒有人有任何創造性的解決方案來加快速度,或誘使方法不檢查每次正確的DLL?

謝謝!

回答

1

我認爲你的問題是不相關的DLL檢查,但簡單的文字渲染。事件ID和條目類型很小。他們可以很快寫出來。消息是BIG通常包含很多文本,因此屏幕渲染需要很長時間。

建議:創建一個StringBuilder並將所有文本添加到它中,而不是重複Console.WriteLines - 然後在最後,執行一個Console.WriteLine(myStringBuilder.ToStrion());

這可能有幫助。

+0

要驗證這是問題,請考慮將輸出直接輸送到文件。如果花費的時間要少得多,那麼你發現了你的問題。 C:\ code \ log \ bin \ debug> MyExe.exe> output.txt – 2011-06-14 23:27:05

+0

由於文件操作通常比內存操作更昂貴,因此我會質疑pipe to file方法,因爲輸出將被緩衝,因此有點不可預知。看到結果雖然很有趣。 – 2011-06-15 02:02:43

+0

如果Console.WriteLine在@ Ben的計算機上與我的一樣慢,它可能容易被混淆爲磁盤IO時間。 (可能確保顯示驅動程序是最新的。) – 2011-06-15 02:05:01