Is iostream slower than printf?

iostream objects are usually slower than printf, but the little efficiency you gain by using printf is not worth avoiding the flexibility of the iostream classes.
(remember: iostream is not only cout, cin.)

iostream objects are usually slower than printf, but the little efficiency you gain by using printf is not worth avoiding the flexibility of the iostream classes.
(remember: iostream is not only cout, cin.)

It is said so, but could you tell me more about the technical details of why iostream is slower?

There are a lot of reasons to love iostream.
Standards don't say that iostream is slower or faster than stdio.
But usually iostream is build by wrapping stdio hence it is usually slower in the current implementations.
Until and unless you have a VERY GOOD REASON to use stdio, I don't prefer to use it.

It is said so, but could you tell me more about the technical details of why iostream is slower?

Can you be more detailed in what you mean with iostream ?
As I said in my previous post: it's a class library for I/O.
Maybe you meant cout versus printf ?

Edit:: http://programming-designs.com/2009/02/c-speed-test-part-2-printf-vs-cout/ (here they measure the performance between both: cout and printf), however I don't know whether you should take this seriously (for example you'll have to take a look at the source to check how the performance tests are performed).

Edit:: But don't follow the advice to use printf instead of cout, instead follow siddhant3s' advice.
(If we have to believe the test, it's only about a few milliseconds, you aren't going to notice the difference, if you can, please tell me)

Can you be more detailed in what you mean with iostream ?
As I said in my previous post: it's a class library for I/O.
Maybe you meant cout versus printf ?

Sorry I should have been more specific. I mean cin, cout and also fstream (ifstream and ofstream).

Sorry I should have been more specific. I mean cin, cout and also fstream (ifstream and ofstream).

How can you compare output performance to input performance ?
(for example: cin versus printf, what's the point of this ?)

How can you compare output performance to input performance ?
(for example: cin versus printf, what's the point of this ?)

I don't mean to compare input and output, I mean to compare cin,cout,ifstream,ofstream with scanf, printf, fscanf, fprintf, respectively.

I don't mean to compare input and output, I mean to compare cin,cout,ifstream,ofstream with scanf, printf, fscanf, fprintf, respectively.

Did you read post #4 of this thread ?

There is no point comparing the difference because such a comparison will be compiler dependent. How one compiler implements cout and printf might be different than how some other compiler implements them. One compiler might wrap cout with printf() while another compiler might wrap cout with win32 api function WriteFile() (in MS-Windows os), bypassing printf() altogether.

, however I don't know whether you should take this seriously

Aah, then why not test it ourselfs?

#include <iostream>
#include <cstdio>
#include <windows.h>


int main(){

    long before = GetTickCount();
    for (unsigned  i = 0; i < 100000; i++) std::cout << "TEXT";
    long coutstring = GetTickCount() - before;

    before = GetTickCount();
    for (unsigned  i = 0; i < 100000; i++) printf("TEXT");
    long printfstring = GetTickCount() - before;

    before = GetTickCount();
    for (unsigned  i = 0; i < 100000; i++) std::cout << i;
    long coutint = GetTickCount() - before;

    before = GetTickCount();
    for (unsigned  i = 0; i < 100000; i++) printf("%d",i);
    long printfint = GetTickCount() - before;

    std::cout << "cout string : " << coutstring << " ms\n";
    std::cout << "printf string : " << printfstring << " ms\n";
    std::cout << "cout int : " << coutint << " ms\n";
    std::cout << "printf int : " << printfint << " ms\n";
}

output on my windows xp- 1.8 ghz centrino:

cout string: 29734 ms
printf string: 12109 ms
cout int: 37235 ms
printf int: 21906 ms

I took a lot bigger loop then the guys in the article, to get more accuracy. But I have to agree with them that printf is nearly twice as fast as cout (on my PC anyway).
But I'd still recommend against using printf with c++.

[edit]
for some reason half of the posts didn't show up when I opened this thread, so the point is already clear that you shouldn't use printf with C++ :)

VC++ 2008 Express on Vista Home Premium with 5 gig RAM 2 Mz CPU, quad core.

Debug build

cout string : 19562 ms
printf string : 6474 ms
cout int : 24368 ms
printf int : 6833 ms
Press any key to continue . . .

Release build

cout string : 18720 ms
printf string : 6115 ms
cout int : 23166 ms
printf int : 6677 ms
Press any key to continue . . .

Code::Blocks V 8.02 release build

cout string : 10671 ms
printf string : 6146 ms
cout int : 11373 ms
printf int : 6645 ms

Process returned 0 (0x0) execution time : 34.873 s
Press any key to continue.

MinGW (Code::Blocks), on Windows Vista Home Premium SP1, 2GB RAM and Dual Core (Intel Pentium D) (Clock Speed per Core = 1.6GHz):

cout string : 12215 ms
printf string : 7020 ms
cout int : 12230 ms
printf int : 7504 ms

cout string : 12137 ms
printf string : 6833 ms
cout int : 11934 ms
printf int : 7238 ms

Real fast

Real fast

Damn slow

Yes yes I know. My other PC is also a quad-core, but I blew my PSU :icon_confused:

Another remark: in nearly all benchmarks, outputting an integer takes longer than a string.

As you can see between posts #12 and #13 speed not only is compiler dependent but also machine dependent.

But I'm surprised to see that Code::Blocks using MinGW produces faster code than VC++ 2008.

Another remark: in nearly all benchmarks, outputting an integer takes longer than a string.

That would be expected because it has to convert int to string before displaying it on the console screen.

We did all this less than a month ago.
http://www.daniweb.com/forums/thread198087.html

Until and unless you have a VERY GOOD REASON to use stdio, I don't prefer to use it.

Debugging, since it usually prints right when you tell it too, while your regular debugger is flipping out.