Re: ls starts VERY SLOWLY w/ b18 on Windows NT 4.0

Re: ls starts VERY SLOWLY w/ b18 on Windows NT 4.0

[Peter Ham]

Wow,
	I figured it out, but it wasn't easy ...
	According to the gnuwin32 b18 readme.txt, b18 adds the intialization of
winsock on startup for all programs.
	My windows nt machine WAS configured to use the microsoft proxy client
when connected to the local lan if the proxy was
available. Since the proxy isn't around, winsock takes a LONG
time (13 seconds or so) to time out. This was happening to me
on all networking programs. I noticed it, but wasn't sure. 
It became unbearable with b18, since even helloworld now took
13 seconds. So, I disabled the ms proxy client winsock and everything
works fine. Wow!
	Thanks for your help!
Peter Ham
Tim Endres wrote:
> 
> I might be wrong. The symlink situation has been identified for
> many cases. If you have a PATH that has directories that are
> symlinks, then it can be slow the first time, then fast after that.
> 
> ----------
> From:   Peter Ham
> Sent:   Sunday, June 15, 1997 7:23 PM
> To:     Tim Endres
> Subject:        Re: ls starts VERY SLOWLY w/ b18 on Windows NT 4.0
> 
> Tim,
>         Are you sure about this diagnosis? Even a
> "hello world" program (does no file access within main()), takes several
> seconds to start up. If I run it immediately again, then it
> seems to start fast, but then if I wait a few seconds, it takes
> a long time again. Could this be a different problem, like maybe
> the cygwin.dll not being cached or someting?
>         I think that you sent me a patch for this. Thanks. But, I'm
> not sure what to do with it.
>         Any ideas would be appreciated.
> 
> Thanks,
> Peter Ham
> 
> Tim Endres wrote:
> >
> > This has been identified as being the result of the new symlink
> > code. It is a known problem, that can be eliminated by hacking
> > out the directory symlink code, or by waiting for optimization
> > in a future release.
> >
> > ----------
> > From:   Peter Ham
> > Sent:   Sunday, May 18, 1997 1:02 AM
> > To:     gnu-win32@cygnus.com
> > Subject:        ls starts VERY SLOWLY w/ b18 on Windows NT 4.0
> >
> > I have noticed that program startup is MUCH SLOWER than
> > the previous release that I downloaded in November or so.
> > It takes 16 seconds on an empty directory on a lightly loaded
> > Pentium 133mhz.
> >
> > Could it be that the cygwin.dll keeps getting loaded and unloaded
> > for each program execution? Is there any way to lock it in?
> > It's frustrating to use "ls" (or any other frequently used program)
> > in this configuration.
> >
> > I also noticed that gcc takes a long time to compile programs,
> > but that the performance monitor indicates that the machine
> > is only lightly loaded in terms of cpu AND io. What's going on?
> > It seems that all of the gnuwin programs are waiting (unnecessarily)
> > on some sychronization or timing event to occur.
> >
> > Has anyone else noticed this?
> >
> > Peter Ham
> >
> > -
> > For help on using this list (especially unsubscribing), send a message to
> > "gnu-win32-request@cygnus.com" with one line of text: "help".
> >
> >     ---------------------------------------------------------------
> >
> >                 Part 1.2       Type: application/ms-tnef
> >                            Encoding: base64
> 
>     ---------------------------------------------------------------
> 
>                 Part 1.2       Type: application/ms-tnef
>                            Encoding: base64

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: ls starts VERY SLOWLY w/ b18 on Windows NT 4.0

[Geoffrey Noer]

Peter Ham wrote:
> 
> I have noticed that program startup is MUCH SLOWER than
> the previous release that I downloaded in November or so.
> It takes 16 seconds on an empty directory on a lightly loaded
> Pentium 133mhz.
> 
> Could it be that the cygwin.dll keeps getting loaded and unloaded
> for each program execution? Is there any way to lock it in?
> It's frustrating to use "ls" (or any other frequently used program)
> in this configuration.

That's very odd.  My main test machine is a fairly normal Micron 166Mhz
Pentium with NT 4.0 server and Windows 95 installed.  It has
32 MB of RAM which isn't a completely obscene amount these days.
I see a definite speed-up in compile times and usage of the various
tools feels snappier.  I should actually measure the time to do configures
under b17 and 18 at some point but it certainly isn't taking 16 seconds
to do an 'ls' of a fairly empty directory for me.

The cygwin.dll in beta 18 does use more RAM, so it could be that the
dll is being swapped in and out of memory.

At the risk of getting hundreds of replies :-), those of you who are seeing
the slow-down:

1) Are you running NT or Win 95?
2) How much RAM?
3) Are you using memory for other open applications when you see the
poor performance?  If so, does cygwin performance increase when you
quit those apps?

Please reply to me directly.  I'll post a summary on the list.

Thanks,

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

ls starts VERY SLOWLY w/ b18 on Windows NT 4.0

[Peter Ham]

I have noticed that program startup is MUCH SLOWER than
the previous release that I downloaded in November or so.
It takes 16 seconds on an empty directory on a lightly loaded
Pentium 133mhz.

Could it be that the cygwin.dll keeps getting loaded and unloaded
for each program execution? Is there any way to lock it in?
It's frustrating to use "ls" (or any other frequently used program)
in this configuration.

I also noticed that gcc takes a long time to compile programs,
but that the performance monitor indicates that the machine
is only lightly loaded in terms of cpu AND io. What's going on?
It seems that all of the gnuwin programs are waiting (unnecessarily)
on some sychronization or timing event to occur.

Has anyone else noticed this?

Peter Ham

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".