转自http://acmer.diandian.com/post/2012-04-10/18636014
我一直以为cin比scanf慢好多...所以比赛从来用scanf直到前两天cf有人说"It’s common knowledge that in order to use cin for big inputs you have to use: ios_base::sync_with_stdio(0); "实测结果如下:
[100000000个int输入]
scanf用时:
real 0m31.640suser 0m30.945ssys 0m0.590s
cin ios_base::sync_with_stdio(1) 用时:real 2m21.258suser 2m20.704ssys 0m0.537s
cin ios_base::sync_with_stdio(0) 用时:real 0m35.687suser 0m35.101ssys 0m0.477s
[100000000个char输入]
scanf用时:real 0m8.905suser 0m8.836ssys 0m0.067scin ios_base::sync_with_stdio(1) 用时:real 0m16.096suser 0m16.012ssys 0m0.080s
cin ios_base::sync_with_stdio(0) 用时:real 0m5.508suser 0m5.460ssys 0m0.047s
测试结果显示,ios_base::sync_with_stdio(0)后,输入int时scanf比cin快一点,但是输入char时scanf比cin慢不止一点。这个估计和parser/scanner的写法有关。当然ios_base::sync_with_stdio(1)时cin无论输入什么都比scanf慢若干倍。结论是造成cin慢的原因是sync_with_stdio,如名称所示,这个是用来保证输入流同步的。关掉同步后cin其实并不比scanf慢,甚至综合来说可能快于scanf(这也是cf上的说法)。在我的测试中,ios_base::sync_with_stdio(1)和ios_base::sync_with_stdio(0)下scanf输入速度不变。据此猜测,因为cin比scanf后实现,所以在开启sync_with_stdio(1)后,为了保持同步,cin没有使用buffer,因为要保持两个buffer的同步可能会很麻烦(又或者是把同步两个buffer的代码全放到了cin这边,以保证较老的scanf不用被修改)。但在sync_with_stdio(0)时,因为不用同步,所以双方都开启buffer。(有兴趣的去看下代码吧)默认 sync_with_stdio ( bool sync = true ); 所以通常来说cin要比scanf慢好多。那个它比较慢的大众印象,其实真心不是它的错。。。当年未深究就想当然接受了"cin比scanf慢"这一结论的我实在是弱爆了。。。--