stdio or iostream??

Write here if you have problems with your C++ source code

Moderator: Board moderators

Post Reply
Khaled_912
New poster
Posts: 33
Joined: Fri Jan 06, 2006 5:51 pm

stdio or iostream??

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
A great helper
Posts: 286
Joined: Tue Mar 25, 2003 8:36 am
Location: calcutta
Contact:

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
A great helper
Posts: 430
Joined: Wed Jun 09, 2004 1:31 pm

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
Learning poster
Posts: 67
Joined: Fri Jul 04, 2003 9:59 am
Location: USA
Contact:

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.
I'm always willing to help, if you do the same.

misof
A great helper
Posts: 430
Joined: Wed Jun 09, 2004 1:31 pm

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.

User avatar
ImLazy
Experienced poster
Posts: 215
Joined: Sat Jul 10, 2004 4:31 pm
Location: Shanghai, China

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?
I stay home. Don't call me out.

misof
A great helper
Posts: 430
Joined: Wed Jun 09, 2004 1:31 pm

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.

Post Reply

Return to “C++”