Why is reading lines from stdin much slower in C++ than Python?

http://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python

by Arkid • 14 years ago

138 26 14 years ago

serialx• 14 years ago

It shows us why just using C/C++ is not a performance-wise decision. You need to spend more time developing the product and spend MORE time to improve it's performance.

meastham• 14 years ago

That's quite a lot to read into a tiny example like this.

_delirium• 14 years ago

I agree, though I think it could fairly be taken as one small bit of evidence in favor of "C++ has a lot of gotchas". In this case it looks like the culprit is C++'s C-compatibility-driven decision to sync with stdio by default, and therefore to avoid buffering input. Of course, if they made the opposite decision on defaults, "C++ doesn't sync with stdio by default" would be a different, probably also common, variety of "gotcha".

mhurron• 14 years ago

I think it more shows that just picking C/C++ over Python doesn't mean you automatically get awesome performance. You still need to know what your doing.

pyrotechnick• 14 years ago

you're

adobriyan2• 14 years ago

like using `gettimeofday()` and not using cat(1), for starters.

jemfinch2• 14 years ago

Whenever this question is asked, it's almost always std::sync_with_stdio.

codemac• 14 years ago

I think it's a larger problem that defaults in standard libraries are rarely understood. For python OR for C++.

I'm asking to the larger Hacker News community here, how do you illustrate the dependencies of a standard library API call without making it more complicated? Syntax is nothing, understanding is everything.

16s• 14 years ago

Yes, and it's an easy fix as the accepted answer shows:

cin.sync_with_stdio(false);

aeurielesn• 14 years ago

The almighty cin has it disadvantages when it comes down to performance. That's why I will always prefer scanf/gets, for a rather simple I/O performance boost.

rwos• 14 years ago

Using gets() also makes writing exploits much quicker - win-win! ;-)

Sorry, I couldn't resist - you are of course right with the general stdio over std::iostream thing, though. I've also found that memory usage and executable size explode when using streams - though that's not C++'s fault per se, more a stdlib/compiler problem.

jjguy• 14 years ago

Reminds me of Joel's Law of Leaky Abstractions. At some point, you must deeply understand the entire stack.

http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

ExpiredLink2• 14 years ago

Real programmers don't use iostream. Seriously.

joelthelion• 14 years ago

Real programmers don't waste time making swooping generalizations about other programmers.

ExpiredLink2• 14 years ago

To be more precise: Real world C++ programmers don't use iostreams as I know from personal experience (more than 10 years of C++ programming).

Edit: Several (more or less successful) attempts have been made for an alternative library. http://accu.org/index.php/journals/1539 for an overview.

alexeiz2• 14 years ago

Indeed they don't. There are no iostreams in FORTRAN.

spullara• 14 years ago

When I/O is slow the first thing to check is to make sure it is buffered. This is true in every language and library. Just turns out this guy ran into something with a default that matches the "read input from terminal" case instead of the "process millions of lines" case.

Why is reading lines from stdin much slower in C++ than Python?

Related Stories