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: <019701c2494f$614e4a40$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
Subject: readv/writev
Date: Wed, 21 Aug 2002 21:14:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

I've been playing around with readv and writev in the cygwin DLL,
and I've changed the code around so that the read and write system
calls delegate to the readv and writev system calls (rather than
vice versa as the current DLL has it).  This then allows
individual fhandler classes to override readv and writev to use
the win32 scatter/gather IO.  I've done this conversion for the
socket class so far.  There is a default readv/writev
implementation in the fhandler_base class that delegates to the
existing read/write methods (w/ optimizations for simple cases and
non-slow devices).

I'd like to submit a patch for this but I'd like to get some
feedback on a performance issue first.  The current DLL code has a
code path something like:

    cygwin_read
        -> fhandler_base::read
            -> fhandler_base::raw_read
                -> ReadFile

while my version would be (for a disk file):

    cygwin_read
        -> cygwin_readv
            -> fhandler_base::readv
                -> fhandler_base::read
                    -> fhandler_base::raw_read
                        -> ReadFile

which is an overhead of two more function calls.  On top of this,
there is I've factored out a function to check the incoming iovec
structure; this makes for an extra overhead of three extra
function calls, plus constructing a minimal iovec structure in
cygwin_read.

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.

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?

// Conrad