2011-01-31 61 views
3

我一直在關閉幾天的問題,列出超出Windows MAX_PATH限制的文件名。 我正在使用Visual Studio 2008以及所有可找到的修補程序。時間是通過QueryPerformanceCounter和公司完成的。iostreams慢。有沒有辦法加速他們?

最新的問題發生在以下代碼:

start = getTime(); 
    for(vector<wstring>::iterator it = files.begin(); it != files.end(); ++it) 
    { 
#if USE_COUT 
      wcout << setw(6) << it->length() << L": " << *it << endl; // 1 
#else 
      wstring x(*it); 
      wprintf(L"%6.6d: %s\n", it->length(), x.c_str());   // 2 
#endif 
    } 
    stop = getTime(); 

上述循環運行在與6755名的條目具有256個字符的平均字符串長度的向量。

通過wcout打印的代碼大約需要52秒才能使用上面的循環顯示矢量。使用wprintf的代碼在大約1.2秒內打印。

如果我最小化控制檯窗口,printf代碼在大約500毫秒內運行,而wcout代碼仍然需要大約40秒。

多年來我一直非常喜歡iostreams,但是......我一直在追求速度問題。在1993/1994使用Borland OS/2編譯器時,我們遇到了一個類似的問題,運行時需要4到6個小時才能完成,使用sprintf運行大約200毫秒的strstream。

任何建議讓我改變我的想法關於iostreams?


編輯:
所有這些關於潮紅的話題都讓我好奇。
是不是 \n在一個 printf字符串在功能上與 std::endl相同的意思是,這兩個字符串都會導致一個換行符和flush發送到輸出?
IIRC, printf沒有 \n不會在某些操作系統上打印,直到填充緩衝區或刷新流(包括Windows在內)爲止。
因此,如果 wprintf("%6.6d: %s\n", length, string)\n刷新,爲什麼不是 wprintfwcout那麼慢呢?

感謝您的意見和建議。我希望在18年前當我開始盜用這些東西時,我已經擁有了它。

+1

這可能是實際的控制檯很慢,不是你的計劃。如果將輸出重定向到`yourprogram> file.txt`文件,或者寫入實際文件而不是wcout,你會得到任何加速嗎? – nos 2011-01-31 11:57:41

+1

如果使用`\ n`而不是`endl`,性能會怎樣? – 2011-01-31 11:59:41

+0

@nos:這比較快速。重定向時只需要2秒就可以了。我可能要工作到一個批處理文件,這使將使用它不會有電腦盲訴諸命令行重定向:)謝謝 – JimR 2011-01-31 12:12:14

回答

8

很可能std::endl行結束符導致性能瓶頸,因爲它在放入換行符後刷新流。在所有輸出結束時將其與'\n'std::wcout << std::flush進行交換。

start = getTime(); 
for(vector<wstring>::iterator it = files.begin(); it != files.end(); ++it) 
{ 
     wcout << setw(6) << it->length() << L": " << *it << '\n'; // 1 
} 
std::wcout << std::flush; 
stop = getTime(); 
2
wcout << setw(6) << it->length() << L": " << *it << endl; // 1 

一個加快的方法是使用"\n"代替endl在循環,如endl不僅僅是一個換行符更多!

1

優化代碼,使其可能是人能跟上滾動文本行不會使一個很大的意義的模糊。重新思考這種方法。輸出到一個文本文件,使用HTML也許看起來不錯,然後啓動一個程序來顯示結果。用戶的眼睛更輕鬆。它會更快地運行lot,無需自動刷新,也無需花時間滾動控制檯。現在只有磁盤I/O是你的瓶頸。

1

由於不是每次迭代都會刷新流(使用'\ n'而不是endl),這很可能會加快你的速度,儘管我的猜測是你仍然會發現printf更快。

您可能會移動運輸及工務局局長的循環之外也順便說一下。

相關問題