我一直在關閉幾天的問題,列出超出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
刷新,爲什麼不是
wprintf
像
wcout
那麼慢呢?
感謝您的意見和建議。我希望在18年前當我開始盜用這些東西時,我已經擁有了它。
這可能是實際的控制檯很慢,不是你的計劃。如果將輸出重定向到`yourprogram> file.txt`文件,或者寫入實際文件而不是wcout,你會得到任何加速嗎? – nos 2011-01-31 11:57:41
如果使用`\ n`而不是`endl`,性能會怎樣? – 2011-01-31 11:59:41
@nos:這比較快速。重定向時只需要2秒就可以了。我可能要工作到一個批處理文件,這使將使用它不會有電腦盲訴諸命令行重定向:)謝謝 – JimR 2011-01-31 12:12:14