This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cygwin slowdown in current cvs version


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@logos-m.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@cygwin.com
Red Hat, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]