Sam writes:
> The reason that I had the redundant buffer clear in the "one write"
> version is so that both benchmarks had the same setup overhead.
But that's not the way it happens in reality. The fill-buffer,
single-write way *doesn't* have that overhead, and so neither should
the test version of it.
Note that no one is saying that your results are wrong; it's obvious
that one big write is faster than many small ones. It's just that
your tests don't look reliable: even if your numbers are accurate, it
seems to have been due in part to chance.
> p=buf;
> for (i=0; i<sizeof(buf); i++)
> *p++=0;
Redundant iterator. Different from how putc works. Use something like:
char* p=buf;
while (p<buf+sizeof buf) *p++=0;
For a truly honest test, we ought to change the code the way it really
would be changed, which probably means using substdio, and comparing
that to the performance of the actual code as it is now. I'm not
familiar with substdio, so I've compared single-byte writes to putc
itself (why emulate at all?):
#include <stdio.h>
#include <unistd.h>
static char buf[BUFSIZ];
int main(int argc, char** argv) {
size_t nloops=2048;
if (argc>1) {
setvbuf(stdout, NULL, _IOFBF, BUFSIZ);
while (nloops--!=0) {
size_t i;
for (i=0; i!=sizeof buf; ++i) putc(42, stdout);
}
} else {
while (nloops--!=0) {
size_t i;
for (i=0; i!=sizeof buf; ++i) {
char c=42;
write(STDOUT_FILENO, &c, 1);
}
}
}
return 0;
}
With this, compiling with no optimization, I get for putc:
real 0m2.994s
user 0m2.410s
sys 0m0.250s
and for single-byte writes:
real 1m10.151s
user 0m7.080s
sys 0m54.040s
Having them write to existing files or creating new ones doesn't seem
to make much difference. Filling my own buffer and doing one big
write(), which is probably a more realistic replacement for the code
in question than putc is, was faster than putc by a factor of 3-4.
Of course, by now, we're way OT for this list.
paul
