Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Message-ID: <01f001c16c12$3615e420$98ed85ce@amr.corp.intel.com> From: "Tim Prince" To: "Charles Wilson" , References: <3BF018AD.9000105@ece.gatech.edu> Subject: Re: cygwin vfork Date: Mon, 12 Nov 2001 17:46:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 ----- Original Message ----- From: "Charles Wilson" To: Sent: Monday, November 12, 2001 10:45 AM Subject: cygwin vfork > Seen on the XEmacs list: > > > In general the cygwin build is slower, I think this is for 3 main > > reasons: > > > > 1) gcc optimization is not as good as MSVC > > 2) The cygwin portability layer adds a lot of overhead especially > > wrt file handling. > > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > the VM size of xemacs. Supposedly a real vfork is in the works for > > cygwin but I can't attest to its functionality. > > Does #3 make any sense? I thought we *had* a real vfork...perhaps it > doesn't work well with large apps? Or is the author just blowing smoke? > > --Chuck > #1 doesn't make a great deal of sense either. I suppose it's possible to set up ground rules under which MSVC would optimize better than gcc, but it's not my experience. -- 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/