Message-ID: <17393e3e0812102233xbcf9778rf0183af8e797f374@mail.gmail.com>
Date: Thu, 11 Dec 2008 01:33:38 -0500
From: "Matt Wozniski" <godlygeek@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Public Cygwin 1.7 test starts today
In-Reply-To: <494061C2.9070306@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081210203400.GA15192@calimero.vinschen.de> 	 <494061C2.9070306@etr-usa.com>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Wed, Dec 10, 2008 at 7:41 PM, Warren Young wrote:
> Can you talk about the positive consequences?  Obviously there's a lot of
> backwards compatibility stuff you can now ignore, and undoubtedly a lot of
> compatibility code that you were able to remove.  I see some features in the
> following list that I suspect were made possible by this, but it'd be nice
> to have a list of what we get for being able to drop this cursed loadstone.
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                   I lol'ed at the reference
> Is Cygwin now significantly faster?

As CGF said, it would be reasonable to bet that it's now slightly
slower, not faster.  Nothing was changed in terms of the slowest parts
of Cygwin (ie, the fork emulation) except for allowing larger
environments, which, without looking at the code, just seems like it
would necessitate more copying and thus slower fork times.  But, all
of that is just conjecture.  Why don't you run some benchmarks for
yourself to find out the performance differences now, while any
problems you find might still be able to be optimized before the final
release?

~Matt

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/