Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <00c501c2496e$39ae2720$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: "Robert Collins" <rbcollins AT cygwin DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
References: <019701c2494f$614e4a40$6132bc3e AT BABEL> <1029971194 DOT 28132 DOT 16 DOT camel AT lifelesswks>
Subject: Re: readv/writev
Date: Thu, 22 Aug 2002 00:55:27 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Robert Collins" <rbcollins AT cygwin DOT 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