fprintf slower than printf and redirect?

[rtillmore]

I finished my program and ran some timing tests and found my program
is slower than the original. The original program just writes
everything to the screen and you have to use >output.txt to capture
the output. I decided to have the program write to the file
directly. So I added a fopen, changed the printf to fprintf(fptr, and
added fclose. When I ran my benchmarks my program ran 2 minutes
slower than the original program with the >output.txt

Is this normal? Is there something I can do to increate the speed of
fprintf? The program is basically a for do loop that calculates
values.

Thanks,

 

[Eric Sosman]

I finished my program and ran some timing tests and found my program
is slower than the original. The original program just writes
everything to the screen and you have to use >output.txt to capture
the output. I decided to have the program write to the file
directly. So I added a fopen, changed the printf to fprintf(fptr, and
added fclose. When I ran my benchmarks my program ran 2 minutes
slower than the original program with the >output.txt

Is this normal?

Hard to say. The C language itself makes no claims about
the relative speeds of any constructs, but ordinarily you'd
expect printf() and fprintf() to take about the same amount
of time. It would be surprising if the program run time rose
from 0:30 to 2:30, but not astounding if it went from 24:00:00
to 24:02:00.

Is there something I can do to increate the speed of
fprintf?

Insufficient information.

The program is basically a for do loop that calculates
values.

What's a "for do loop?" No, don't try to explain: Just
whittle your code down to a short, complete, compilable program
that demonstrates the problem, and post that shortened code.

 

[Phil Carmody]

I finished my program and ran some timing tests and found my program
is slower than the original. The original program just writes
everything to the screen and you have to use >output.txt to capture
the output. I decided to have the program write to the file
directly. So I added a fopen, changed the printf to fprintf(fptr, and
added fclose. When I ran my benchmarks my program ran 2 minutes
slower than the original program with the >output.txt

Is this normal? Is there something I can do to increate the speed of
fprintf? The program is basically a for do loop that calculates
values.

Perhaps the streams had different buffering?
Investigate setvbuf and friends.
Note, however, that the C language makes no promises about
the speed of any constructs or library functions, and therefore
your question is entirely platform specific. You might have more
luck asking in a newsgroup specifically aimed at that platform.

Phil

 

[Barry Schwarz]

I finished my program and ran some timing tests and found my program
is slower than the original. The original program just writes
everything to the screen and you have to use >output.txt to capture
the output. I decided to have the program write to the file
directly. So I added a fopen, changed the printf to fprintf(fptr, and
added fclose. When I ran my benchmarks my program ran 2 minutes
slower than the original program with the >output.txt

Is this normal? Is there something I can do to increate the speed of

When you redirect the output, how often is the disk actually written
to (how many lines are buffered)? How does this compare with the
fprintf code?

fprintf? The program is basically a for do loop that calculates

How about a timing test comparing printf and fprintf directed to
stdout. That will tell you if fprintf is the culprit (and I will bet
you determine it is not).

 

[rtillmore]

Hard to say. The C language itself makes no claims about
the relative speeds of any constructs, but ordinarily you'd
expect printf() and fprintf() to take about the same amount
of time. It would be surprising if the program run time rose
from 0:30 to 2:30, but not astounding if it went from 24:00:00
to 24:02:00.


Insufficient information.


What's a "for do loop?" No, don't try to explain: Just
whittle your code down to a short, complete, compilable program
that demonstrates the problem, and post that shortened code.

/* If I compile this program on linux: gcc test.c -o test and run test
like this #time ./test
I get these results:
real 3m12.035s
user 0m4.676s
sys 0m8.125s

if I run test like this #time ./test >output
I get these results:
real 0m2.322s
user 0m1.940s
sys 0m0.360s

if I change writefile to 1, recompile, and run test like this #time ./
test
I get these results
real 0m2.645s
user 0m1.872s
sys 0m0.428s

*/

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main () {
unsigned long long int i;
int writefile=1;
FILE *fptr;

if (writefile==0) {
for (i=1;i<1350000;i++) {
printf("i*i = %ull\n",i*i);
printf("ix2 = %ull\n",i*2);
printf("i-i = %ull\n",i-i);
printf("i/i = %ull\n",i/i);
printf("i*i++ = %ull\n",i*i++);
printf("i+i++ = %ull\n",i+i++);
printf("i-i++ = %ull\n",i-i++);
printf("i/i++ = %ull\n",i/i++);
}
}
else {
if((fptr = fopen("TEMP","w")) == NULL) {
printf("File TEMP could not be opened\n");
}
else {
for (i=1;i<1350000;i++) {
fprintf(fptr,"i*i = %ull\n",i*i);
fprintf(fptr,"ix2 = %ull\n",i*2);
fprintf(fptr,"i-i = %ull\n",i-i);
fprintf(fptr,"i/i = %ull\n",i/i);
fprintf(fptr,"i*i++ = %ull\n",i*i++);
fprintf(fptr,"i+i++ = %ull\n",i+i++);
fprintf(fptr,"i-i++ = %ull\n",i-i++);
fprintf(fptr,"i/i++ = %ull\n",i/i++);
}
(void)fclose(fptr);
}
}
return 0;
}

 

[Eric Sosman]

[...]
if I run test like this #time ./test >output
I get these results:
real 0m2.322s
user 0m1.940s
sys 0m0.360s

if I change writefile to 1, recompile, and run test like this #time ./
test
I get these results
real 0m2.645s
user 0m1.872s
sys 0m0.428s

What happened to the "my program ran 2 minutes slower"
when changing from printf()/redirect to fprintf()? Looks
to me like the time difference was 0.323 seconds, about
twenty-seven ten-thousandths the magnitude you reported
earlier, and well within the likely measurement noise.

 

[Ben Bacarisse]

Eric wrote:

/* If I compile this program on linux: gcc test.c -o test and run test
like this #time ./test
I get these results:
real 3m12.035s
user 0m4.676s
sys 0m8.125s

if I run test like this #time ./test >output
I get these results:
real 0m2.322s
user 0m1.940s
sys 0m0.360s

if I change writefile to 1, recompile, and run test like this #time ./
test
I get these results
real 0m2.645s
user 0m1.872s
sys 0m0.428s

I get almost the same results for each version. After a few runs of
each I think the redirected one was a shade faster, but they were so
close on a statistical analysis would settle the matter.

*/

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main () {
unsigned long long int i;
int writefile=1;
FILE *fptr;

if (writefile==0) {
for (i=1;i<1350000;i++) {
printf("i*i = %ull\n",i*i);
printf("ix2 = %ull\n",i*2);
printf("i-i = %ull\n",i-i);
printf("i/i = %ull\n",i/i);
printf("i*i++ = %ull\n",i*i++);
printf("i+i++ = %ull\n",i+i++);
printf("i-i++ = %ull\n",i-i++);
printf("i/i++ = %ull\n",i/i++);
}
}
else {
if((fptr = fopen("TEMP","w")) == NULL) {
printf("File TEMP could not be opened\n");
}
else {
for (i=1;i<1350000;i++) {
fprintf(fptr,"i*i = %ull\n",i*i);
fprintf(fptr,"ix2 = %ull\n",i*2);
fprintf(fptr,"i-i = %ull\n",i-i);
fprintf(fptr,"i/i = %ull\n",i/i);
fprintf(fptr,"i*i++ = %ull\n",i*i++);
fprintf(fptr,"i+i++ = %ull\n",i+i++);
fprintf(fptr,"i-i++ = %ull\n",i-i++);
fprintf(fptr,"i/i++ = %ull\n",i/i++);
}
(void)fclose(fptr);
}
}
return 0;
}

I don't think I have seen this much UB in one program for a while!
The correct format for unsigned long long is %llu. Changing that
nearly doubled the run-time but there where both still close.

 

[Ralf Damaschke]

I don't think I have seen this much UB in one program for a while!
The correct format for unsigned long long is %llu. Changing that
nearly doubled the run-time but there where both still close.

Well spotted, I did not notice. But it has still heavy UB in the
last arguments of the last 4 [f]printf calls.

-- Ralf