This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: readv/writev


"Robert Collins" <rbcollins@cygwin.com> wrote:
>
> Conrad Scott wrote:
> >
> > On my m/c, a 900Mhz Pentium III (?), the same test
> > program I was using for the __stdcall / regparm testing
> > (read 16Mb from /dev/zero one byte at a time and write
> > to /dev/zero) takes about 3 seconds longer with the
> > readv/writev changes.  That is, ~38.6 seconds rather
> > than ~35.6 seconds.  So, it's measurable but it's a
> > pretty extreme test.
>
> how long does it take if you read in a readv block of,
> say 1000 elements? Faster or slower?

I'm not clear quite what you're asking here, which probably means
I've not explained very well what I was up to in the first place
:-(  The slow down I'm reporting is a constant overhead per
read/write call (of approx. a tenth of a microsecond?).  So the
speed of the two implementations will always differ by:

    no. of reads and writes * 0.1 microsecond

> > Does anyone feel this is important?  If so, I can
> > write separate code paths for both read/write as well
> > as readv/writev, which would then be no slower than the
> > current DLL code.  The issue then is a small increase
> > in DLL size along with more duplicate code to maintain.
> >
> > Any votes?

> 1) Implement a clean design.

Certainly gets my vote (assuming I can manage to achieve it).

> 2) *IF* the readv->read code is fairly short,
> put it in a header so it can inline when appropriate.

I think 72 lines with several conditionals and loops is not short
(whether "fairly" or otherwise).

> 3) Implement 'native' Overlapped IOw/  scatter-gather
> for NT OS's on disk files. :}.

Well, yes, I would do but it's all a bit complex and stuff, you
know?

For binary-mode files we could get close, since ReadFile and
WriteFile take an array of WSABUF structures which are isomorphic
to readv/writev's iovec structures.  The problem is then mapping
NT's overlapped mode into some vaguely plausible Posix interface,
otherwise all that we've gained is the ability to avoid one
memcpy, tho' that's not to be sneezed at.  And for sockets, the
use of readv/writev can be important as it avoids the whole Nagle
algorithm mess that you get into with a sequence of "small"
writes.

// Conrad




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]