Question

I am reading about 3 million rows from a file and inserting them into STL maps. So, inside my while loop where I read each line from the file, I also print to console what row number it is through a simple cout statement. One of my friends recently pointed out that this makes code slower. I was wondering whether it is true and if it is why?

Answer 1

As already mentioned, writing to the terminal is almost definitely going to be slower. Why?

• depending on your OS, std::cout may use line buffering – which means each line may be sent to the terminal program separately. When you use std::endl rather than ‘\n’ it definitely flushes the buffer. Writing the data in smaller chunks means extra system calls and rendering efforts that slow things down significantly.

• some operating systems / compilers are even slower – for example, Visual C++: https://connect.microsoft.com/VisualStudio/feedback/details/642876/std-wcout-is-ten-times-slower-than-wprintf-performance-bug-in-c-library

• terminals displaying output need to make calls to wipe out existing screen content, render the fonts, update the scroll bar, copy the lines into the history/buffer. Especially when they get new content in small pieces, they can’t reliably guess how much longer they’d have to wait for some more and are likely to try to update the screen for the little bit they’ve received: that’s costly, and a reason excessive flushing or unbuffered output is slow.

  • Some terminals offer the option of “jump scrolling” which means if they find they’re say 10 pages behind they immediately render the last page and the earlier 9 pages of content never appear on the screen: that can be nice and fast. Still, “jump scrolling” is not always used or wanted, as it means output is never presented to the end users eyes: perhaps the program is meant to print a huge red error message in some case – with jump scrolling there wouldn’t even be a flicker of it to catch the user’s attention, but without jump scrolling you’d probably notice it.

  • when I worked for Bloomberg we had a constant stream of log file updates occupying several monitors – at times the displayed output would get several minutes behind; a switch from the default Solaris xterm to rxvt ensured it always kept pace

• redirecting output to /dev/null is a good way to see how much your particular terminal is slowing things down