mixing cout and printf for faster output

Question

After performing some tests I noticed that printf is much faster than cout. I know that it's implementation dependent, but on my Linux box printf is 8x faster. So my idea is to mix the two printing methods: I want to use cout for simple prints, and I plan to use printf for producing huge outputs (typically in a loop). I think it's safe to do as long as I don't forget to flush before switching to the other method:

cout << "Hello" << endl;
cout.flush();

for (int i=0; i<1000000; ++i) {
    printf("World!\n");
}
fflush(stdout);

cout << "last line" << endl;
cout << flush;

Is it OK like that?

Update: Thanks for all the precious feedbacks. Summary of the answers: if you want to avoid tricky solutions, simply stick with cout but don't use endl since it flushes the buffer implicitly (slowing the process down). Use "\n" instead. It can be interesting if you produce large outputs.

Benzo

I'm not 100% sure, but my guess is that inside of a loop, building a string and then printing that once would be far faster than printing out a separate string every time. – Aitchbone

Sometimes this is not very useful though such as whenever the printf serves as a logging function to alert the user there is still progress being made – Eschar

@earlz - Very true indeed, I just thought I would mention it in case. – Aitchbone

@Topher Fangio: what is the C++ equivalent of the Java StringBuilder? As I know, unlike in Java, string concatenation is very efficient in C++. Is it OK to create a string and append new snippets to it with +=? – Benzo

Have you determined that printing is your bottleneck? If not, then an 8x speedup might not matter much at all. – Giordano

It's been a while since I did C++, but this post is similar to what I would say: #611763 – Aitchbone

The primary preference between cout and printf is safety and adaptability. The direction in programming should be correctness and robustness first, then performance. – Basanite

Move the fflush() inside the loop and try it again. That will make the printf loop functionally equivalent to the cout loop, since endl sends an implicit fflush to the stream. – Bartholemy

Answer 1

The direct answer is that yes, that's okay.

A lot of people have thrown around various ideas of how to improve speed, but there seems to be quite a bit of disagreement over which is most effective. I decided to write a quick test program to get at least some idea of which techniques did what.

#include <iostream>
#include <string>
#include <sstream>
#include <time.h>
#include <iomanip>
#include <algorithm>
#include <iterator>
#include <stdio.h>

char fmt[] = "%s\n";
static const int count = 3000000;
static char const *const string = "This is a string.";
static std::string s = std::string(string) + "\n";

void show_time(void (*f)(), char const *caption) { 
    clock_t start = clock();
    f();
    clock_t ticks = clock()-start;
    std::cerr << std::setw(30) << caption 
        << ": " 
        << (double)ticks/CLOCKS_PER_SEC << "\n";
}

void use_printf() {
    for (int i=0; i<count; i++)
        printf(fmt, string);
}

void use_puts() {
    for (int i=0; i<count; i++) 
        puts(string);        
}

void use_cout() { 
    for (int i=0; i<count; i++)
        std::cout << string << "\n";
}

void use_cout_unsync() { 
    std::cout.sync_with_stdio(false);
    for (int i=0; i<count; i++)
        std::cout << string << "\n";
    std::cout.sync_with_stdio(true);
}

void use_stringstream() { 
    std::stringstream temp;
    for (int i=0; i<count; i++)
        temp << string << "\n";
    std::cout << temp.str();
}

void use_endl() { 
    for (int i=0; i<count; i++)
        std::cout << string << std::endl;
}

void use_fill_n() { 
    std::fill_n(std::ostream_iterator<char const *>(std::cout, "\n"), count, string);
}

void use_write() {
    for (int i = 0; i < count; i++)
        std::cout.write(s.data(), s.size());
}

int main() { 
    show_time(use_printf, "Time using printf");
    show_time(use_puts, "Time using puts");
    show_time(use_cout, "Time using cout (synced)");
    show_time(use_cout_unsync, "Time using cout (un-synced)");
    show_time(use_stringstream, "Time using stringstream");
    show_time(use_endl, "Time using endl");
    show_time(use_fill_n, "Time using fill_n");
    show_time(use_write, "Time using write");
    return 0;
}

I ran this on Windows after compiling with VC++ 2013 (both x86 and x64 versions). Output from one run (with output redirected to a disk file) looked like this:

          Time using printf: 0.953
            Time using puts: 0.567
   Time using cout (synced): 0.736
Time using cout (un-synced): 0.714
    Time using stringstream: 0.725
            Time using endl: 20.097
          Time using fill_n: 0.749
           Time using write: 0.499

As expected, results vary, but there are a few points I found interesting:

1. printf/puts are much faster than cout when writing to the NUL device
• but cout keeps up quite nicely when writing to a real file
2. Quite a few proposed optimizations accomplish little
   • In my testing, fill_n is about as fast as anything else
3. By far the biggest optimization is avoiding endl
4. cout.write gave the fastest time (though probably not by a significant margin

I've recently edited the code to force a call to printf. Anders Kaseorg was kind enough to point out--that g++ recognizes the specific sequence printf("%s\n", foo); is equivalent to puts(foo);, and generates code accordingly (i.e., generates code to call puts instead of printf). Moving the format string to a global array, and passing that as the format string produces identical output, but forces it to be produced via printf instead of puts. Of course, it's possible they might optimize around this some day as well, but at least for now (g++ 5.1) a test with g++ -O3 -S confirms that it's actually calling printf (where the previous code compiled to a call to puts).

Keffiyeh

Thank you for the thorough test. I always thought that endl was simply an alias to "\n". As I can see, endl calls a flush too, while using "\n" will do buffering, just like printf. – Benzo

@Jerry Coffin: excellent answer! I never realized that avoiding std::endl could give such a speed-jump. – Remake

Excellent answer, but on VCpp Express 2010 it's needed to include <iterator> as well otherwise this error will be shown: "error C2039: 'ostream_iterator' : is not a member of 'std'" – Douro

To compile with gcc and clang, <cstdio> (or <stdio.h>) needs to be included. Thanks. – Gesellschaft

Be careful about inferring anything from the results of this benchmark on GCC or clang, because they both optimize the specific pattern printf("%s\n", string) into puts(string) at every optimization level. – Himyaritic

@AndersKaseorg: Thanks for the heads-up. I've fixed it (at least until they introduce still more optimization to recognize what I've done). – Keffiyeh

With my g++ (4.9.2), your new version with char const fmt[] = "%s\n"; still gets optimized to puts. Removing the const seems to be sufficient to prevent this. – Himyaritic

@JerryCoffin for picture completeness it would be interesting to see the same test results done on windows with ms compiler and libs. – Shool

Although I've run it with other compilers as well, the times shown in the answer are (as noted) from running the code with MS VC++ on Windows. It's VC++ 2013, which is a few versions old by now; I may rerun with 2017, but I wouldn't expect to see a major change. – Keffiyeh

@Pavel: I just re-ran the code with VC++ 2017 on Windows. I'm using a different drive now (an SSD instead of a rotating hard drive), which improves the write bandwidth, making all the numbers somewhat faster--but for C I/O vs. iostreams, it makes no real difference. – Keffiyeh

Answer 2

Sending std::endl to the stream appends a newline and flushes the stream. The subsequent invocation of cout.flush() is superfluous. If this was done when timing cout vs. printf then you were not comparing apples to apples.

Eldoraeldorado

For the comparative test I used two separate functions without flushing and executed the prg. twice, calling one method and the other. In this example I just wanted to demonstrate the "mixing" of the two methods. – Benzo

I suspect the reason cout is slower is that it is flushing after every line. printf flushes only when a buffer fills up or you explicitly flush. Flushes are expensive because they energize the mechanical parts of the disk. – Tamandua

Would it be possible to switch off cout's autoflush on std::endl and thus make it similar to printf? – Benzo

To answer my previous comment: use "\n" instead of endl to avoid flush after each line. See also #1925030 . – Benzo

@Jabba: I bet a lot of people would like to know that. – Tamandua

Answer 3

By default, the C and C++ standard output streams are synchronised, so that writing to one causes a flush of the other, so explicit flushes are not needed.

Dolphin

Answer 4

Also, note that the C++ stream is synced to the C stream.
Thus it does extra work to stay in sync.

Another thing to note is to make sure you flush the streams an equal amount. If you continuously flush the stream on one system and not the other that will definitely affect the speed of the tests.

Before assuming that one is faster than the other you should:

• un-sync C++ I/O from C I/O (see sync_with_stdio() ).
• Make sure the amount of flushes is comparable.

Smaragd

I think you are conflating tie() with sync_with_stdio() – Dolphin

Answer 5

You can further improve the performance of printf by increasing the buffer size for stdout:

setvbuf (stdout, NULL, _IOFBF, 32768);  // any value larger than 512 and also a
                  // a multiple of the system i/o buffer size is an improvement

The number of calls to the operating system to perform i/o is almost always the most expensive component and performance limiter.

Of course, if cout output is intermixed with stdout, the buffer flushes defeat the purpose an increased buffer size.

Lavonia

Answer 6

You can use sync_with_stdio to make C++ IO faster.

cout.sync_with_stdio(false);

Should improve your output perfomance with cout.

Riproaring

Except then you do have to perform explicit flushes to mix the C++ and C style output funcytions, so you are not likely to gain much, if anything. – Dolphin

This should remove the need for using both. Havent used it myself, but I heard a number of long speeches from classmates on how much faster cout is using this. – Riproaring

@Neil: When cout is synced with stdio, how often are flushes? I'd expect they would flush after every << operator, at least, since << doesn't know if the next operation is printf() and I'd be surprised if stdio has a dependency on (i.e. synchronizes with) iostreams. – Marola

Just wondering, when we do cout.sync_with_stdio(false);, we are unsyncing the two streams. Isn't it the opposite of what we wanted to do? – Remake

Answer 7

Don't worry about the performance between printf and cout. If you want to gain performance, separate formatted output from non-formatted output.

puts("Hello World\n") is much faster than printf("%s", "Hellow World\n"). (Primarily due to the formatting overhead). Once you have isolated the formatted from plain text, you can do tricks like:

const char hello[] = "Hello World\n";
cout.write(hello, sizeof(hello) - sizeof('\0'));

To speed up formatted output, the trick is to perform all formatting to a string, then use block output with the string (or buffer):

const unsigned int MAX_BUFFER_SIZE = 256;
char buffer[MAX_BUFFER_SIZE];
sprintf(buffer, "%d times is a charm.\n", 5);
unsigned int text_length = strlen(buffer) - sizeof('\0');
fwrite(buffer, 1, text_length, stdout);

To further improve your program's performance, reduce the quantity of output. The less stuff you output, the faster your program will be. A side effect will be that your executable size will shrink too.

Basanite

The assertion that puts is much faster than printf is unfounded in most cases. In fact, printf performs almost as well as puts in most implementations I've investigated. It's never worse than 2:1 and more frequently somewhere around 1.3:1 or 1.2:1. – Lavonia

@Lavonia and at least nowadays, every compiler I've bothered to check actually straight up replaces printf call with puts where appropriate, completely pointless to do it by hand or worry about it. – Sowder

Answer 8

Well, I can't think of any reason to actually use cout to be honest. It's completely insane to have a huge bulky template to do something so simple that will be in every file. Also, it's like it's designed to be as slow to type as possible and after the millionth time of typing <<<< and then typing the value in between and getting something lik >variableName>>> on accident I never want to do that again.

Not to mention if you include std namespace the world will eventually implode, and if you don't your typing burden becomes even more ridiculous.

However I don't like printf a lot either. For me, the solution is to create my own concrete class and then call whatever io stuff is necessary within that. Then you can have really simple io in any manner you want and with whatever implementation you want, whatever formatting you want, etc (generally you want floats to always be one way for example, not to format them 800 ways for no reason, so putting in formatting with every call is a joke).

So all I type is something like dout+"This is more sane than "+cPlusPlusMethod+" of "+debugIoType+". IMO at least"; dout++;

but you can have whatever you want. With lots of files it's surprising how much this improves compile time, too.

Also, there's nothing wrong with mixing C and C++, it should just be done jusdiciously and if you are using the things that cause the problems with using C in the first place it's safe to say the least of your worries is trouble from mixing C and C++.

Ajay

It's not insane to use a template instead of a format string -- templates are typesafe and eliminate the need for a format string parsing step at runtime. Of course, using an I/O system as slow as C++ iostreams for more than a trivial amount of work would be insane, but the slowness does not come from the templates. – Doubleheader

Answer 9

Mixing C++ and C iomethods was recommended against by my C++ books, FYI. I'm pretty sure the C functions trample on the state expected/held by C++.

Laparotomy

C++ is designed to play with C i/o methods - remember, you are talking about a single runtime here. – Dolphin

I dimly remember mixing C and C++ I/O under older versions of GCC incurred a performance hit. For all I know, it still could, but I haven't seen this mentioned recenly. Perhaps that's why the books were against it? – Philippopolis

I'm glad they play nice now. I remember strange things happening years ago, last time I tried (gcc 2.72 or somesuch; I remember having to explicitly instantiate my templates with #pragmas), and because of that I've avoided mixing them. Besides, where I work people are vehemently anti-iostreams. (I don't have a problem with them except for their excessive verbosity due to extreme overuse of operator overloading; I printed a lot of fixed-width 0-prefixed hex values and the formatters for those are insane.) – Marola

Neil: I don't recall why anymore; it's been literally years. outtis: perhaps. – Laparotomy

I think it was GCC 2.95 that I was thinking of. GCC 3 might have fixed the performance hit. – Philippopolis