Mail Archives: cygwin-developers/2001/09/08/16:23:38
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.
- Raw text -