RE: Mozilla 1.3 built on cygwin?

["Chris January" <chris at atomice dot net>]

> 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/