在http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly的50:40处，Andrei Alexandrescu开了一个关于istream效率不高/慢的玩笑。
我曾经遇到过ostream速度慢的问题，在运行主循环时，fwrite明显要快得多(可以节省几秒钟)，但我从来没有理解为什么，也没有深入研究过。
是什么导致C++中的istream和ostream变慢？或者至少比其他东西(如fread/fget, fwrite)慢，这些同样可以满足需求。
std::cin，std::cout 等时，需要调用 std::sync_with_stdio(false)！如果没有进行此调用，任何使用标准流对象都需要与 C 的标准流同步。当然，使用 std::sync_with_stdio(false) 时，假定你不会将 std::cin 与 stdin 混淆，std::cout 与 stdout 混淆等。
不要使用 std::endl，因为它会强制刷新缓冲区，导致许多不必要的刷新。同样，不要设置 std::ios_base::unitbuf 或不必要地使用 std::flush。共享格式状态：每个格式化输出操作都必须检查之前可能被I/O操纵符改变的所有格式化状态。因此，iostreams比类似于printf的API（特别是像Rust或{fmt}中的格式字符串编译那样避免解析开销）慢得多，其中所有格式化信息都是局部的。
无法控制的区域设置使用：即使您不希望如此，所有格式化都会通过一个低效的区域设置层进行处理，例如在编写JSON文件时。请参见N4412: iostreams的缺点。
低效的代码生成：使用iostreams格式化消息通常包括多个格式化函数调用，因为参数和I/O操纵符与消息的各个部分交错。例如，在以下等效的printf调用中有三个这样的调用（godbolt）：
std::cout << "The answer is " << answer << ".\n";
而在等效的printf调用中只有一个调用（godbolt）：
printf("The answer is %d.\n", answer);
这些格式化函数调用中的每一个都有很大的开销（见上文）。
额外的缓冲和同步。可以通过sync_with_stdio(false)禁用此功能，但会导致与其他I/O设施的互操作性差。
#include <stdio.h>
#include <iomanip>
#include <iostream>
#include <iterator>
#include <fstream>
#include <time.h>
#include <string>
#include <algorithm>
unsigned count1(FILE *infile, char c) {
int ch;
unsigned count = 0;
while (EOF != (ch=getc(infile)))
if (ch == c)
++count;
return count;
}
unsigned int count2(FILE *infile, char c) {
static char buffer[8192];
int size;
unsigned int count = 0;
while (0 < (size = fread(buffer, 1, sizeof(buffer), infile)))
for (int i=0; i<size; i++)
if (buffer[i] == c)
++count;
return count;
}
unsigned count3(std::istream &infile, char c) {
return std::count(std::istreambuf_iterator<char>(infile),
std::istreambuf_iterator<char>(), c);
}
unsigned count4(std::istream &infile, char c) {
return std::count(std::istream_iterator<char>(infile),
std::istream_iterator<char>(), c);
}
unsigned int count5(std::istream &infile, char c) {
static char buffer[8192];
unsigned int count = 0;
while (infile.read(buffer, sizeof(buffer)))
count += std::count(buffer, buffer+infile.gcount(), c);
count += std::count(buffer, buffer+infile.gcount(), c);
return count;
}
unsigned count6(std::istream &infile, char c) {
unsigned int count = 0;
char ch;
while (infile >> ch)
if (ch == c)
++count;
return count;
}
template <class F, class T>
void timer(F f, T &t, std::string const &title) {
unsigned count;
clock_t start = clock();
count = f(t, 'N');
clock_t stop = clock();
std::cout << std::left << std::setw(30) << title << "\tCount: " << count;
std::cout << "\tTime: " << double(stop-start)/CLOCKS_PER_SEC << "\n";
}
int main() {
char const *name = "equivs2.txt";
FILE *infile=fopen(name, "r");
timer(count1, infile, "ignore");
rewind(infile);
timer(count1, infile, "using getc");
rewind(infile);
timer(count2, infile, "using fread");
fclose(infile);
std::ifstream in2(name);
timer(count3, in2, "ignore");
in2.clear();
in2.seekg(0);
timer(count3, in2, "using streambuf iterators");
in2.clear();
in2.seekg(0);
timer(count4, in2, "using stream iterators");
in2.clear();
in2.seekg(0);
timer(count5, in2, "using istream::read");
in2.clear();
in2.seekg(0);
timer(count6, in2, "using operator>>");
return 0;
}
ignore Count: 1300 Time: 0.309
using getc Count: 1300 Time: 0.308
using fread Count: 1300 Time: 0.028
ignore Count: 1300 Time: 0.091
using streambuf iterators Count: 1300 Time: 0.091
using stream iterators Count: 1300 Time: 0.613
using istream::read Count: 1300 Time: 0.028
using operator>> Count: 1300 Time: 0.619
并且这个（使用MinGW）：
ignore Count: 1300 Time: 0.052
using getc Count: 1300 Time: 0.044
using fread Count: 1300 Time: 0.036
ignore Count: 1300 Time: 0.068
using streambuf iterators Count: 1300 Time: 0.068
using stream iterators Count: 1300 Time: 0.131
using istream::read Count: 1300 Time: 0.037
using operator>> Count: 1300 Time: 0.121
虽然这个问题很老了，但我很惊讶没有人提到iostream对象的构造。
也就是说，每当你创建一个STL的iostream（以及其他流变体），如果你进入代码，构造函数就会调用内部的Init函数。在那里，会调用operator new来创建一个新的locale对象。
同样，在销毁时也会被销毁。
在我看来，这很丑陋。并且肯定会导致对象构造/销毁变慢，因为在某些时候会使用系统锁来分配/释放内存。
此外，STL流中的一些流允许您指定一个allocator，那么为什么不使用指定的allocator来创建locale呢？
在多线程环境中使用流时，您还可以想象每次构造新流对象时调用operator new所带来的瓶颈。
如果你问我，我认为这是一团糟，因为我现在自己也发现了！