Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Chris January" <chris AT atomice DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: Mozilla 1.3 built on cygwin?
Date: Sat, 29 Mar 2003 11:18:37 -0000
Message-ID: <LPEHIHGCJOAIPFLADJAHEEKLDHAA.chris@atomice.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <20030329001348.GA1533@redhat.com>

> On Sat, Mar 29, 2003 at 12:04:01AM -0000, Chris January wrote:
> >> On Thu, Mar 27, 2003 at 11:58:50PM +0100, Ralf Habacker wrote:
> >>>I can't prove a fact, that forking is the most anonying problem and
> >>>there were some initial work from some people (I remember Chris Faylor,
> >>>Chris January and other) to identify the problems and to implement a
> >>>new copy-on-write semantic, which will be much faster,
> >>
> >>You misremember.  I did hobble together a copy-on-write implementation
> >>and found that it was actually slower.  The generic win32
> >>implementation of copy-on-write isn't powerful enough to completely
> >>implement fork anyway.
> >
> >Noone has explained, however, *why* the copy-on-write implementation
> >was slower.  Perhaps we have just been using the wrong tests.  Does
> >copy-on-write actually perform slower in "real world" tests?  I don't
> >know, because I only used the skeleton example found in Nebbit's book.
>
> I implemented it with both the win32 api and with the skeleton example.
> Neither was a speed daemon.  I can't think of a better test than doing a
> bunch of forks and measuring the results.  Who knows why it is slower?
> Maybe ReadProcessMemory is doing copy-on-write already or something.

For the record my own tests involved a single parent process forking, then
sleeping for a set period of time and exiting. The child process wrote all
over the heap while the parent was sleeping, thus forcing all of the shared
pages to be copied. This was faster with Cygwin's fork than with the
copy-on-write fork, even with Cygwin's extra process launching overhead, but
I could not explain why. My copy-on-write fork code doesn't work on XP SP1
so I can't retest right now.

Chris


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/