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

原文：http://hi.baidu.com/i5love1you9/item/2b97cb3dd91f20b7134b14c5

每周的训练作业，题意就是两个递增序列，输出合并后新序列的中值，刚开始也没怎么在意，认为该题思路是对的就能AC。可提交的结果却TLE了，当时就郁闷了，这算法不可能会有问题啊，不就是一个简单的归并而已。我坚信算法肯定是没问题的，那问题究竟出在哪儿了呢？很快便锁定问题的症结在于输入输出，其实刚开始并不确定，虽然很早以前就知道cin，cout比scanf，printf要慢，可一直没在意，认为即使有差别也不会太大吧，但这次“血淋淋”的事实就是cin，cout就TLC，scanf，printf就AC了。于是，一个问题“cin,cout与scanf，printf速度上的差别到底有多大”便出现在脑海中。

cin慢的原因是，默认情况，cin与stdin总是保持同步的，也就是说这两种方法可以混用，而不必担心文件指针混乱，同时cout和stdout也一样，两者混用不会输出顺序错乱。正因为这个兼容性的特性，导致cin有许多额外的开销，如何禁用这个特性呢？只需一个语句std::ios::sync_with_stdio(false);，这样就可以取消cin于stdin的同步了，此时的cin就与scanf差不多了。

cin、cout是在编译期间就决定了读入变量的类型。而scanf()是在运行期决定的，编译器无法优化，而且还要识别字符串。理论上scanf比cin要慢很多，实际上快的原因是很多编译器对cin、cout的处理过于保守VS测，结果却相反，理论上cin，cout比scanf，printf要快，实际中是由于编译器的处理方式导致了scanf，printf比cin，cout快了。

 

总结下来就是：

①scanf至少要比cin快一倍左右

②cin慢的原因：默认情况，cin与stdin总是保持同步的，也就是说这两种方法可以混用，而不必担心文件指针混乱，同时cout和stdout也一样，两者混用不会输出顺序错乱。正因为这个兼容性的特性，导致cin有许多额外的开销。（解决：只需一个语句std::ios::sync_with_stdio(false);，这样就可以取消cin于stdin的同步了，此时的cin就与scanf差不多了）

③cin、cout是在编译期间就决定了读入变量的类型。而scanf()是在运行期决定的，编译器无法优化，而且还要识别字符串。理论上scanf比cin要慢很多，实际上快的原因是很多编译器对cin、cout的处理过于保守。

④同牛人建议，Acmer 尽量用scanf,printf来进行输入输出吧....