C ++標準是否要求iostream的性能不佳，或者我只是處理糟糕的實現？每當我提到C ++標準庫iostream的慢性能時，我都會遇到一陣難以置信的風潮。然而，我有剖析器結果顯示在iostream庫代碼中花費了大量時間（完全編譯器優化），并且從iostream切換到特定于操作系統的I / O API和自定義緩沖區管理確實提供了一個數量級的改進。C ++標準庫做了多少額外工作，標準是否需要它，它在實踐中是否有用？或者有些編譯器提供了與手動緩沖區管理競爭的iostream實現嗎？基準為了解決問題，我編寫了幾個簡短的程序來練習iostreams內部緩沖：將二進制數據放入ostringstream http://ideone.com/2PPYw將二進制數據放入char[]緩沖區http://ideone.com/Ni5ctvector<char>使用http://ideone.com/Mj2Fi將二進制數據放入其中back_inserter新：vector<char>簡單的迭代器http://ideone.com/9iitv新：將二進制數據直接放入stringbuf http://ideone.com/qc9QA新：vector<char>簡單的迭代器加邊界檢查http://ideone.com/YyrKy請注意，ostringstream和stringbuf版本運行的迭代次數較少，因為它們的速度要慢得多。在ideone上，它ostringstream比std:copy+ back_inserter+ 慢大約3倍std::vector，比memcpy原始緩沖區慢大約15倍。當我將實際應用程序切換到自定義緩沖時，這與前后分析一致。這些都是內存緩沖區，因此iostream的緩慢不能歸咎于緩慢的磁盤I / O，過多的刷新，與stdio的同步，或者人們用來解釋C ++標準庫觀察到的緩慢的任何其他事情iostream的。很高興看到其他系統上的基準測試和常見實現的評論（例如gcc的libc ++，Visual C ++，Intel C ++）以及標準規定了多少開銷。此測試的基本原理許多人都正確地指出，iostream更常用于格式化輸出。但是，它們也是C ++標準提供的二進制文件訪問的唯一現代API。但是對內部緩沖進行性能測試的真正原因適用于典型的格式化I / O：如果iostreams無法保持磁盤控制器提供原始數據，那么當他們負責格式化時，他們怎么可能跟上呢？基準時間所有這些都是outer（k）循環的每次迭代。在ideone上（gcc-4.3.4，未知的操作系統和硬件）：ostringstream：53毫秒stringbuf：27毫秒vector<char>并且back_inserter：17.6毫秒vector<char> 與普通迭代器：10.6毫秒vector<char> 迭代器和邊界檢查：11.4 mschar[]：3.7毫秒在我的筆記本電腦上（Visual C ++ 2010 x86，cl /Ox /EHscWindows 7旗艦版64位，Intel Core i7,8 GB RAM）：ostringstream：73.4毫秒，71.6毫秒stringbuf：21.7 ms，21.3 msvector<char>和back_inserter：34.6毫秒，34.4毫秒vector<char> 與普通迭代器：1.10毫秒，1.04毫秒vector<char> 迭代器和邊界檢查：1.11 ms，0.87 ms，1.12 ms，0.89 ms，1.02 ms，1.14 mschar[]：1.48毫秒，1.57毫秒VISUAL C ++ 2010 x86上，與檔案導引優化cl /Ox /EHsc /GL /c，link /ltcg:pgi運行，link /ltcg:pgo，措施：ostringstream：61.2 ms，60.5 msvector<char> 與普通迭代器：1.04毫秒，1.03毫秒相同的筆記本電腦，相同的操作系統，使用cygwin gcc 4.3.4 g++ -O3：ostringstream：62.7 ms，60.5 msstringbuf：44.4毫秒，44.5毫秒vector<char>和back_inserter：13.5毫秒，13.6毫秒vector<char> 使用普通迭代器：4.1 ms，3.9 msvector<char> 迭代器和邊界檢查：4.0毫秒，4.0毫秒char[]：3.57毫秒，3.75毫