Difference in iostream console output performance between Windows and OSX?

Question

the following very simple loop is given:

int main (void) { for (int i = 0 ; i < 1000000; i++) { std::cout<<i<<std::endl; } } 

running this code on pure Windows 8 Professional using Microsoft Visual Studio 2012 takes about 15 seconds for every 100,000 prints.

On mac os x, using the same computer, it only takes 3 seconds for xcode to output 1 mill line.

I’m almost 100% sure that it has nothing to do with performance, and it’s just something that is related to the mechanics of output or something else.

Can someone confirm this ...? just to find out my windows and visual studio are fine.

Answer 1

std::endl run the line. It is quite expensive for this.

Try to do:

 std::cout << i << '\n'; 

In most other normal interactive I / O scenarios, std :: endl is redundant when used with std :: cout, because any input from std :: cin, output to std :: cerr, or program termination causes the call to std :: cout.flush ( )

Using std :: endl instead of '\ n' , caused by some sources, can significantly degrade output performance.

Source

---

EDIT: The withdrawal operation is expensive and depends on external factors. That is why it is slow here. For example, the terminal application used may be a factor in some performance issues.

You can avoid this by redirecting the output to /dev/null/ :

 ./a.out > /dev/null 

For output performance, you can read this: http://codeforces.com/blog/entry/5217

Answer 2

It depends on external factors. Like the terminal application. For example, on OS X and Linux, you can bypass the terminal and start it with:

  ./program> / dev / null

It completes in about 0.2 seconds.

I / O in standard C ++ is a blocking operation. This means that the program freezes while it expects the OS to process the output. In the end, if the terminal application is not so fast, this will cause the program to be "frozen" in the standby state quite a lot.

Answer 3

Please note that this is more reflection on my part, but still:

What I suspect is that the difference (by the way, Windows / OSX) in the overall runtime of your small test program has nothing to do with the code generated by the corresponding compiler.

From my experience working with console output on Windows, I strongly suspect that the bottleneck here is dragging personal data from your program to the Windows console and cmd.exe is displayed.

It just might be that the console / shell / bash on OSX accepts program output much faster than the Windows console.

What you can try is to redirect the output of this program to a file (using the redirection at startup in the CLI test.exe > output.txt ) and see if you can measure any difference this way.