cin,cout与scanf,printf
2014-03-13 17:13
411 查看
昨天在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
#include
#include
using namespace std;
const int NUM = 1000000;
int main()
{
ofstream file("data");
for(int i = 0 ; i < NUM ; i++)
{
file<<rand()<<' ';
if((i+1) == 0)
file<<endl;
}
return 0;
}
(2)测试cin读取这1000000个数所用的时间
#include
#include
#include
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
#include
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。
带着诸多疑问,我决定自己亲自测测。于是编写了如下代码:
(1)随机生成1000000个数,并将它们写到文件data中
#include
#include
#include
using namespace std;
const int NUM = 1000000;
int main()
{
ofstream file("data");
for(int i = 0 ; i < NUM ; i++)
{
file<<rand()<<' ';
if((i+1) == 0)
file<<endl;
}
return 0;
}
(2)测试cin读取这1000000个数所用的时间
#include
#include
#include
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
#include
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。
相关文章推荐
- eclipse C/C+ CDT中scanf、cin、 printf、cout不能debug输入输出的问题
- cin,cout与scanf,printf的效率问题
- scanf printf 与cin cout 时间的差别
- C++的cin/cout为什么比C语言的scanf/printf慢
- c++中cin/cout与scanf/printf的区别比较
- cin,cout与scanf,printf的速度到底相差多少
- 如果你想知道cin,cout究竟和scanf,printf速度上有什么差别~~
- cin,cout与scanf,printf的速度到底相差多少
- scanf&printf VS cin&cout
- [笔记]cin、cout与scanf、printf的效率差异对比分析
- C++-cin与scanf cout与printf效率问题
- boj problem 1330 顺利AC 注意输入或输出数据较多时 scanf printf 比cin cout快非常多~
- 再一次看到了cin cout比scanf和printf耗时。(有关文件差异的比较方法在后面)
- cin cout输入输出pk printf scanf
- printf,scanf,cin,cout的输入输出
- 关于printf/scanf 与 cin/cout 输入输出的速度研究
- 讨论C++的cin/cout与C的scanf/printf
- cin,cout,printf,scanf效率对比
- 在PAT这个oj中还是scanf和printf的耗时少于cin和cout
- 【C++】cin、cout的效率比scanf和printf低的解决方法