Mail Archives: cygwin-developers/2002/08/01/18:20:23
On Thu, Aug 01, 2002 at 11:17:02PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <cgf AT redhat DOT com> wrote:
>> So, it's possible that my current implementation is actually
>slower than
>> the old one. I'll check on that in the next couple of days.
>
>I've just done some timings with a pair of test programs, where
>the server echoes everything it's sent and the client repeatedly
>sends packets and waits for replies. They also do a select before
>each read from the socket (I've got a problem with selects for
>writing so that's not in the test program as yet).
>
>Anyhow, timings (done with bash's time command, averages over 3
>runs):
>
>Before Chris's changes:
>
>real 29.9 seconds
>user 1.8 seconds
>system 6.75 seconds
>
>After the changes:
>
>real 23.4
>user 1.3
>system 4.88
>
>which is a nice 20% improvement, not slower at all.
>
>Just for comparison, the same test w/o any selects:
>
>real 1.1
>user 0.15
>system 0.30
>
>so there's still some room for improvement :-)
I think I can whittle that down some. I'm amazed that the difference
was so great. I'm even more amazed that there is THAT much overhead
in select(). Wow.
>Of course, the other point here is that the code seems to work
>fine (I'm also running XEmacs w/ gnuserv and CVS too).
>
>// Conrad
>
>p.s. I've been assuming that bash's time command returns sensible
>values for the user and system times: they look plausible. Are
>they known to be good?
You know, that's a good question. I have been using /bin/time and
noticing that there may be something funny there because sometimes I get
elapsed times that are less than the total of system and user time. I
guess that's possible given my dual processor machine but I don't recall
ever seeing that before.
cgf
- Raw text -