cin,cout与scanf，printf的速度到底相差多少

转载自百度空间 http://hi.baidu.com/i5love1you9/item/2b97cb3dd91f20b7134b14c5
昨天在OJ上看到一个很水的题，题意就是两个递增序列，输出合并后新序列的中值(详细描述可参见我的另一篇文章http://hi.baidu.com/i5love1you9/blog/item/250f57d671b6f41aa08bb721.html)。当时也闲来无事，于是决定动手写写。刚开始也没怎么在意，认为该题随便都能AC。可提交的结果却TLE了，当时就郁闷了，这算法不可能会有问题啊，不就是一个简单的归并而已，我写的再搓也不可能会TLE啊（小小地自恋一下，哈哈）。我坚信算法肯定是没问题的，那问题究竟出在哪儿了呢？很快便锁定问题的症结在于输入输出，其实刚开始并不确定，虽然很早以前就知道cin，cout比scanf，printf要慢，可一直没在意，认为即使有差别也不会太大吧，但这次“血淋淋”的事实就是cin，cout就TLC，scanf，printf就AC了。于是，一个问题“cin,cout与scanf，printf速度上的差别到底有多大”便出现在脑海中。晚上跑步的时候，将该问题告诉了霏哥，霏哥测试了cin与scanf，但结果却大大出乎了我们的预料，cin竟然比scanf快！怎么回事？这不可能啊，难道霏哥的方法不对，这也不大可能啊(我可是绝对相信霏哥的哦，哈哈)。

带着诸多疑问，我决定自己亲自测测。于是编写了如下代码：

（1）随机生成1000000个数，并将它们写到文件data中

#include <iostream>

#include <fstream>

#include <cstdlib>

using namespace std;

const int NUM = 1000000;

int main()

{

ofstream file("data");

for(int i = 0 ; i < NUM ; i++)

{

file<<rand()<<' ';

if((i+1)%20 == 0)

file<<endl;

}

return 0;

}



（2）测试cin读取这1000000个数所用的时间

#include <iostream>

#include <ctime>

#include <cstdio>

using namespace std;

const int NUM = 1000000;

int main()

{

freopen("data","r",stdin);

int n,start,end;

start = clock();

for(int i = 0 ; i < NUM ; i++)

cin>>n;

end = clock();

cout<<double(end-start)/CLOCKS_PER_SEC<<endl;

return 0;

}

（3）测试scanf读取这1000000个数所用的时间

#include <ctime>

#include <cstdio>

const int NUM = 1000000;

int main()

{

freopen("data","r",stdin);

int n,start,end;

start = clock();

for(int i = 0 ; i < NUM ; i++)

scanf("%d",&n);

end = clock();

printf("%lf\n",double(end-start)/CLOCKS_PER_SEC);

return 0;

}

在VS1010上测试的结果是：cin 0.234s,scanf 0.421s。怎么回事？真的如霏哥所测的，cin竟然比scanf快。这下我彻底懵了，这到底是怎么回事？ 于是上网百度，找了好久才看到相关一篇文章，作者分别测试了linux和windows平台上常用的几款编译器下scanf和cin的速度，结果显示scanf至少要比cin快一倍左右。文中还指出cin慢的原因是，默认情况，cin与stdin总是保持同步的，也就是说这两种方法可以混用，而不必担心文件指针混乱，同时cout和stdout也一样，两者混用不会输出顺序错乱。正因为这个兼容性的特性，导致cin有许多额外的开销，如何禁用这个特性呢？只需一个语句std::ios::sync_with_stdio(false);，这样就可以取消cin于stdin的同步了，此时的cin就与scanf差不多了。

但是为什么我在VS2010上测试的结果却大相径庭呢？莫非是测试方法不对？这不可能啊，我个人这点自信还是有的。那这到底是什么原因呢？带着满脑子的疑问和不解，我继续看着那篇文章，终于在评论部分，有位网友提到，cin、cout是在编译期间就决定了读入变量的类型。而scanf()是在运行期决定的，编译器无法优化，而且还要识别字符串。理论上scanf比cin要慢很多，实际上快的原因是很多编译器对cin、cout的处理过于保守。按着这位网友的说法，理论上cin，cout比scanf，printf要快，实际中是由于编译器的处理方式导致了scanf，printf比cin，cout快了。

带着疑问，我又用g++测试了一下，当然没有带任何优化选项，g++版本为4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)。结果果然是我预期的：cin 1.1s ，scanf 0.41s。

这似乎证实了理论上cin，cout比scanf，printf要快，实际中是由于编译器的处理方式导致了scanf，printf比cin，cout快了，至少我的实验结果是和这个说法稳合的。也许还有其他的原因，恳请各位牛人网友热心赐教，鄙人将感激不尽。

最后，算是一个建议吧，其实你肯定已经听别人说过很多次了，在OJ上做题尽量使用scanf和printf，尤其是有大量数据需要输入输出时，当然你也可以用取消了同步的cin。