Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sat, 8 Sep 2001 22:23:26 +0200 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: cygwin slowdown in current cvs version Message-ID: <20010908222326.B937@cygbert.vinschen.de> Reply-To: cygdev Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <130160175780 DOT 20010908204017 AT logos-m DOT ru> <127165775081 DOT 20010908221336 AT logos-m DOT ru> <186168543292 DOT 20010908225944 AT logos-m DOT ru> <20010908155203 DOT C12571 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010908155203.C12571@redhat.com>; from cgf@redhat.com on Sat, Sep 08, 2001 at 03:52:03PM -0400 On Sat, Sep 08, 2001 at 03:52:03PM -0400, Christopher Faylor wrote: > On Sat, Sep 08, 2001 at 10:59:44PM +0400, egor duda wrote: > >Hi! > > > >Saturday, 08 September, 2001 egor duda deo AT logos-m DOT ru wrote: > > > >ed>> did anybody noticed that cygwin runs slower than before? i've just > >ed>> tried to perform full rebuild of newlib and received the following > >ed>> results: > > > >[...] > > > >ed> Yet, it's only half of the story. cvs build from just before this > >ed> change still work slower than the build i've used daily since the > >ed> beginning of August. I'll try to dig a little deeper now. > > > >ok. after going back to as far as 1st of June i've started to think > >that i should probably take some lessons in, ehr, positive thinking :) > > > >it looks like the rest 10% of slowdown is not actually a "slowdown" > >but rather a 10% speedup... I don't remember for sure but it looks > >pretty much like i've been running my locally-hacked version of > >cygwin1.dll, which replaced statically-allocated /dev/dsp buffer with > >malloc()ed one. I'm not sure if such change could account for 10% of > >performance, but we're getting too close to the statistical noise > >threshold here to know for sure. > > > >To resume. I think we should back out Corinna's "reread /etc/passwd" > >patch for now, wait for some time until dust settles, and release > >1.3.3. after that i'll try to remake my /dev/dsp patch and see what > >performance gains it gives (if any). I think we should do that. I'm thinking of a different way to do the same by starting an additional thread which wakes up on a file change event or something. AFAICS there's a call in Windows which allows that on changes to a directory but not on changes to a single file. Anyway, perhaps that's sufficient for the /etc directory. What do you think? > Have you compared the numbers against 1.3.2 by any chance? > > It occurred to me today that by moving the large zombies buffer into the > heap, I ended up having fork always copy the array. I don't know which > is better -- having a large dll with a slower load time vs more to copy > on fork. Hum, I would prefer the larger DLL in that case. The DLL is loaded once, the fork is pretty often. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.