stdio or iostream??

Khaled_912 · Post by **Khaled_912** » Mon Jan 09, 2006 6:17 am

I've always wondered which is faster to use: scanf and printf or the cin and cout?
It might seems a useless question, but I'm just curious to know which is faster, if any.

sumankar · Post by **sumankar** » Mon Jan 09, 2006 10:42 am

The C style io routines work better at times, or so I have seen. I doubt though, if it can be
generalized. Depends on the percentage of runtime you spend on IO, I believe.

misof · Post by **misof** » Mon Jan 09, 2006 11:14 am

IMHO it can be generalized, in all versions of g++ I have seen (including the one used at UVa) scanf is much faster than cin. The difference between printf and cout isn't that significant, but still printf is quite a bit faster.

Still, as Suman already said, this only matters if the input/output is significantly large, say in the order of hundreds of kilobytes or more.

Ryan Pai · Post by **Ryan Pai** » Tue Jan 10, 2006 8:06 pm

As misof said, scanf/printf are significantly faster than cin/cout. I've been hit by this on quite a few problems (including one I recently solved that took me about 20 submits). Most of the problems that are really that critical on runtime are in the earlier volumes and I find in such cases that I have to a) use scanf/printf instead of cin/cout and b) avoid any use of the STL. If you persistently get TLE, and you think using cin might be the culprit check the boards, usually someone else will have had the same problem (though not always).

Alternatively, when the runtime isn't that important (other than using the right algorithm that is), I always use cin/cout. I find them to be more flexible.

misof · Post by **misof** » Tue Jan 10, 2006 8:10 pm

Ryan Pai wrote:b) avoid any use of the STL.

This is mainly due to the fact that the g++ settings at UVa judge don't include any optimization.

ImLazy · Post by **ImLazy** » Sun Jan 22, 2006 6:48 pm

misof wrote:This is mainly due to the fact that the g++ settings at UVa judge don't include any optimization.

Do you mean STL is not slow itself, but slow in UVA?

misof · Post by **misof** » Mon Jan 23, 2006 8:30 pm

ImLazy wrote:
misof wrote:This is mainly due to the fact that the g++ settings at UVa judge don't include any optimization.
Do you mean STL is not slow itself, but slow in UVA?

Exactly. The g++ implementation of STL is pretty efficient, but some parts of it rely on compiler optimizations quite heavily. There is quite a difference between compiling a STL-using program with no optimization and compiling it with -O2 (or better).

I think that UVa judge admins were forced to remove the optimization because in contest their judge couldn't handle the load. Compilation with -O2 takes a longer time, and it matters if you have to compile and test 1000 solutions as quickly as possible. Still, it's a shame and it's giving programs using STL quite a disadvantage.