(part 50) Han from China answers your C questions
- From: Anonymous <cripto@xxxxxxx>
- Date: Sat, 29 Nov 2008 08:49:44 +0100 (CET)
fprintf slower than printf and redirect?
rtillmore@xxxxxxxxx said:
/* 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 have a new comp.lang.c modus operandi. Please see my updated
signature.]
Hey, buddy.
I'll let others go on about the sequence points, side effects,
etc., and how the undefined behavior could include causing
your program to run 2 minutes slower.
I think in your original post, you may have gotten a few things
backward in your description, since the timing results above
appear to contradict your original description. But then again,
I'm sure you would've noticed scrolling terminal output vs.
the other two outputs and the time differences, so I dunno.
The very slow timing (the first one above, presumably with
writefile==0) is for normal terminal output, correct? That's
a normal time. The other two times are virtually the same.
Since you're running Linux, my first thought was that
this had something to do with weird buffering. On many
Unix and Unix-like systems, terminal output is line-buffered
by default, whereas file output is fully-buffered by
default (these default behaviors don't violate the C
standard). I'd imagined some kind of weird behavior with
the redirected output keeping line-buffering, but this
wouldn't really explain your observations at all, I
don't think.
Assuming nobody else comes up with anything, please explain
more about the first timing information above, and I'll
see what comes to mind.
Yours,
Han from China
All my posts will have subjects containing the words "Han from
China" or "Han from China's". This is so people can easily killfile
me if they wish and all replies to me. Many of the regulars on
comp.lang.c have expressed difficulty in killfiling both a poster
AND all replies to that poster - witness comments along the lines
of "I've killfiled XXX [I promise. Really!], but I'm seeing XXX's
stupid comments in your reply to XXX. [So therefore I simply must
reply to those comments like the uncontrolled sniping weasel I am.]"
There are 3 posting IDs that my gateways randomly assign me: George
Orwell, Nomen Nescio, and Borked Pseudo Mailed. You can killfile
those too if you wish. Other than that, my posts have a highly
consistent format as well, which also aids with killfiles. For those
who want to join me in a mature discussion of the C programming
language and aid one another's understanding, standard advice
applies: Don't Feed The Trolls. If you ignore them, eventually
they'll get bored and go away. Thank you and good luck with your
C programming. Update: To mark the 50th part of my series, I will
now be replying in-thread to redirect OPs to my series posts
out-thread. This is after observing that many of these OPs aren't
looking at other threads. I was going to limit myself to replying
in-thread and stop my series posts altogether, but that still has
the problem with the regulars who don't know how to killfile
both a poster and all replies to that poster. To compromise, I'll
keep my in-thread redirection messages very short and end all
in-thread messages with my usual close for easy killfiling purposes.
This way, there's nothing about C to reply to, so any replies that
escape the regulars' killfiles aren't my problem. If I see a
significant reduction in weasel sniping in-thread, which is unfair
on people who wish to killfile me and any insults about me, I'll
end my series altogether and limit myself to in-thread replies.
I still can't inject a "References" header though, so I'm assuming
that if I use the same subject line as the original message,
most newsreaders will or can be made to thread properly.]
.
- Follow-Ups:
- Re: (part 50) Han from China answers your C questions
- From: Phil Carmody
- Re: (part 50) Han from China answers your C questions
- Prev by Date: fprintf slower than printf and redirect?
- Next by Date: (part 50) Han from China answers your C questions
- Previous by thread: z error
- Next by thread: Re: (part 50) Han from China answers your C questions
- Index(es):
Relevant Pages
|