C ++标准是否要求iostream的性能较差,或者我只是在处理较差的实现?
每当我提到C ++标准库iostream的性能下降时,我都会感到一阵怀疑。但是,我的探查器结果显示,大量时间花费在iostream库代码(完整的编译器优化)上,从iostream切换到特定于操作系统的I / O API和自定义缓冲区管理确实提高了一个数量级。 C ++标准库正在做什么额外的工作,它是标准所必需的,并且在实践中是否有用?还是某些编译器提供了与手动缓冲区管理竞争的iostream实现? 基准测试 为了使事情顺利进行,我编写了一些简短的程序来练习iostream的内部缓冲: 将二进制数据放入ostringstream http://ideone.com/2PPYw 将二进制数据放入char[]缓冲区http://ideone.com/Ni5ct vector<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:如果iostream无法为磁盘控制器提供原始数据,那么当它们负责格式化时又如何保持正常运行呢? 基准时间 所有这些都是外部(k)循环的每次迭代。 在ideone上(gcc-4.3.4,未知的操作系统和硬件): ostringstream:53毫秒 stringbuf:27毫秒 vector<char>和back_inserter:17.6毫秒 vector<char> 普通迭代器:10.6毫秒 vector<char> 迭代器和边界检查:11.4毫秒 char[]:3.7毫秒 在我的笔记本电脑上(Visual C …