Dumb I/O Performance Question

I have a dumb question regarding performance using printf. Is there any difference in the code below? In the first example would there be an I/O burst everytime I called printf or would the compiler optimize the code and combine it into one burst like the second example?

Code:

---

printf("My name is Bob");
printf("I like green apples");
printf("My favorite color is red");
printf("I live in a blue house");

---

Code:

---

printf("My name is Bob\nI like green apples\nMy favorite color is red\nI live in a blue house");

---

Quote:

---

Originally Posted by BENCHMARKMAN

I have a dumb question regarding performance using printf. Is there any difference in the code below? In the first example would there be an I/O burst everytime I called printf or would the compiler optimize the code and combine it into one burst like the second example?

---

I would highly doubt that the compiler would perform concatenation of non-adjacent strings. And I would be highly suspect of any such compiler that "optimized" in the fashion you describe.

So what you are saying is that version 2 is faster especially if I say had 20 different threads performaning this operation.

I would pay absolutely no attention to any perceived nanoseconds savings until I had taken the time to rigorously profile my program and find that this odd portion of code (somehow) produced an unacceptable performance hit. Until that time, I'm not going to concern myself with it. YMMV

printf does not insert newlines into your output.

You could do this:

Code:

---

printf("%s",
    "My name is Bob\n"
    "I like green apples\n"
    "My favorite color is red\n"
    "I live in a blue house\n");

---

I guess the main thing I am trying to get at is that there is only one I/O burst compared to 4.

I don't care enough to try to work out an actual example, but I would guess you would get 4 "bursts" in both examples, since stdout is flushed on every newline character.

Edit: obviously I'm assuming a "fixed" example where the four strings weren't printed without spaces together on one line (or until wrap).

Quote:

---

Originally Posted by BENCHMARKMAN

I guess the main thing I am trying to get at is that there is only one I/O burst compared to 4.

---

I don't even know whether you can know that, or that one is supposed to care. AFAIK, a call to printf loads some buffer that the operating system gets around to handling at its leisure. Consecutive calls or no, it's the OS that is doing your burst, not the code. Line buffering, etc. options requested and what-not, it's still the OS's call.

It depends.

Usually, stdout is buffered, unless you changed that.

So it should be actually written to disk in a few or one burst, but it might not if it filled up the buffer.

Using more than one function call will usually probably make the program run on the CPU a bit slower, but it probably won't make enough difference to slow down the file io operation in general, because the operation is file io bound.

If you do this:

"String" "string2" then the strings will be made one by the preprocessor like this:

"Stringstring2"

And you theoretically have lower overhead.

But it probably won't make that much difference unless that's all this program does and on something other than files (like ramdisks or something).

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

I believe most people will agree with this. Indeed, i do, since when i start thinking first about optimizing my code, it often gives bad-looking merely-working code. :)

The best performance hit can be gained by using, on this simple case of unformatted output, io functions that do not care about formatting.

Code:

---

char s[] ="A really really long string spanning over many many lines\
,\nand having embedded\t\tcharacters\n\
and various other things and needed to be\n written very fastly\
to the standard output.\nHow to do it?\n";

fwrite(s, sizeof(s), 1, stdout);

---

That's probably as fast as it can get...

Efficencly is actually a secondary effect of what I am trying to accomplish. I'm creating 20 thread that print debut and using multiple printf statments causes the output to be interleaved.

So you were wondering what would happen if using multiple printf statements?
Well i think that chances are that a thread might be stopped before finishing all of it's printf statements, and another thread starts printing it's own and then again it might even stop during the execution of a printf statement, unless you somehow do a lock on the output sections of your threads the output will most certainly be interleaved.

Quote:

---

Originally Posted by xuftugulus

So you were wondering what would happen if using multiple printf statements?
Well i think that chances are that a thread might be stopped before finishing all of it's printf statements, and another thread starts printing it's own and then again it might even stop during the execution of a printf statement, unless you somehow do a lock on the output sections of your threads the output will most certainly be interleaved.

---

When using VS with MT version or CRT library printf will definitely NOT stopped inside outputting the string

However, strings posted from different printfs (or over output functions) could and will interleave.

Quote:

---

Originally Posted by vart

When using VS with MT version or CRT library printf will definitely NOT stopped inside outputting the string

However, strings posted from different printfs (or over output functions) could and will interleave.

---

What is VS with MT version or CRT library printf ? Is that the standard printf()?

Visual Studio provides several versions of standard CRT library, Multi-threaded versions have internal locking in the IO functions

Quote:

---

Originally Posted by BENCHMARKMAN

Efficencly is actually a secondary effect of what I am trying to accomplish. I'm creating 20 thread that print debut and using multiple printf statments causes the output to be interleaved.

---

If you must use the same output stream, and you want to stop interleaving, you can serialize them via a global mutex and use fflush():

Code:

---

        /* body of individual thread */
        pthread_mutex_lock(&output_mutex);
        fprintf(stdout, "individual thread output 1\n");
        fprintf(stdout, "individual thread output 2\n");
        fprintf(stdout, "individual thread output 3\n");
        fprintf(stdout, "individual thread output 4\n");
        fflush(stdout);
        pthread_mutex_unlock(&output_mutex);

---

I wouldn't even waste time looking for this to be a significant bottleneck either, unless you're pumping out lots of output - and if you are, you're hitting other locks anyways.

better yet - implement some queue and loggerThread

All threads post their logs to queue (using appropriate locking)
One thread - does nothing except reading from the queue and printing messages
This will prevent blocking working threads due to IO delays
On the other hand loggerThread will be mostly waiting for IO operation complition without using to much CPU

Thanks for the replies. I didn't really want to use a mutex becaues the printf() is already in a locked section.