This is the mail archive of the 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]
Other format: [Raw text]

Re: ls.exe slow down in cygwin 1.3.13 (a followup from the "ls problem" thread last november 2002)

Sorry, I accidentally pressed <ctrl-enter> in my outlook and the message was sent without me finishing it.  Here's the finished
message. My deepest apologies:

Good Day Cygwineers (cygwin engineers),

Last November 2002, I've upgraded cygwin and encountered a variation in the behaviour of ls.  ls, when invoked as "ls -l" takes a
bit longer to execute than the previous cygwin version.  (I've attached the output of cygehck.)  I haven't upgraded cygwin since
November 2002 last year since I'm content with my installation now.  The current variation in the behaviour of ls is not really a
problem but I'd be glad if I could let it behave as it used to.

I've posted the this observation last year in the list (under the thread "ls -problem" and I thank everyone for their replies.     Sorry if I just did a follow-up now
(after 6 months) since I didn't have time to worry about my cygwin setup several days after I posted my observation.   After some
days of doing some research on what could be the solution to make ls behave as it used to, I finally said I'd just be content with
the way it is.  But now that I've got time to answer all the replies, I hope we could find a solution to the issue.

I don't plan to upgrade my cygwin installation since it behaves very well and my current needs do not demand that I upgrade cygwin

Here's the gist of the problem:

Whenever ls is invoked as "ls -l", the output takes somewhat longer.  I tried timing the output and here are the results:

I'm working on my ~/foo directory.  The directory contains 2 items: bar and strace.txt.  bar is an empty directory and strace.txt is
a regular text file.

case 1) ls invoked plainly

fcarlo@THORIN ~/foo
$ time ls
bar  strace.txt

real    0m0.028s
user    0m0.030s
sys     0m0.015s

case 2) ls is invoked as "ls -l"

fcarlo@THORIN ~/foo
$ time ls -l
total 49
drwxr-xr-x    2 fcarlo   None            0 Jun 30 11:20 bar
-rw-r--r--    1 fcarlo   None        49394 Jun 30 11:08 strace.txt

real    0m1.924s
user    0m0.030s
sys     0m0.046s

I've tried repeating the invocation of "ls -l" in the hope that the list would be cached.  After invoking it several times, there is
no significant change in the time it takes to execute.

I've tried stracing the output of "ls -l" and I've attached the output of strace too.
An observation on the output of strace is that the delay starts when line 442 is printed.

Line 442 of the strace output is:

104 1970355 [main] ls 2012 _open: -1 = open (/usr/local/etc/zoneinfo/posixrules, 0x10000)

I'm wondering what this zoneinfo/posixrules is.  The file does not exist in my installation.

Here are my collated responses to the replies by the gurus:

Reply to Igor Pechtchanski:

>It would have been more helpful if you had provided your cygwin version,
>but even without it I could venture a guess...  The latest
> versions of cygwin have ntsec on by default, and doing 'ls -l' will result in the user
> lookup in the /etc/passwd (and /etc/group) file.  An easy way to test that
> is to time 'ls -ln' and see if it's faster.

There is no improvement in the speed after I've tested ls -ln

> Another test would be to *temporarily* turn off ntsec (by adding "nontsec" to your CYGWIN
> environment variable and reloading cygwin1.dll by exiting all running
> cygwin processes).

Still no improvement.  I've exited all cygwin processes, set the CYGWIN environment variable to nontsec via control panel, and the
output didn't change.  Then, I've exited all processes again, set CYGWIN to ntsec, run ls -ln, and still didn't work.

Reply to Randall Schulz:

> I think your next step must be to run "ls" under "strace" and
> see where the excess time (presumably idle time) is going.

I've attached it now.  Thanks.

Reply to Pierre Humblet:

> There is a huge delay accessing
> F:\cygwin\usr\local\etc\zoneinfo\posixrules,
> on your F: drive.
> What's that?

The file does not exist in my F drive.

Reply to David Starks-Browning:

>Do you have any anti-virus software running?

Reply to Randall Schulz:

> Could there be a Windows mount (not a Cygwin mount) active for that directory that refers to
> a network drive letter with an invalid server association? (Is that even possible?)

I've got no network drives mounted.

> Carlo, you could try one of these commands:
>mountvol 'F:\cygwin\usr\local\etc' /l
>mountvol 'F:\cygwin\usr\local\etc\zoneinfo' /l
>mountvol 'F:\cygwin\usr\local\etc\zoneinfo\posixrules' /l

The output for mountvol 'F:\cygwin\usr\local\etc' /l is:

fcarlo@THORIN ~
$ mountvol 'F:\cygwin\usr\local\etc' /l
The file or directory is not a reparse point.

For mountvol 'F:\cygwin\usr\local\etc\zoneinfo' /l, the output is:
fcarlo@THORIN ~
$ mountvol 'F:\cygwin\usr\local\etc\zoneinfo' /l
The system cannot find the file specified.

For mountvol 'F:\cygwin\usr\local\etc\zoneinfo\posixrules' /l, the output is:

fcarlo@THORIN ~
$ mountvol 'F:\cygwin\usr\local\etc\zoneinfo\posixrules' /l
The system cannot find the path specified.

Reply to Igor Pechtchanski:

>Try running 'ls -l' first to pull the directory contents and the stat
>records for the files into memory, and then repeating both 'time ls' and
>time ls -l' commands, and see if that makes a difference in the timings.

The cache does not work.  After running "ls -l", then "time ls -l" several times, there is still no improvement.

Reply to cgf:

> The delay is apparently ls doing things that haven't been straced.  I don't
> know what could be causing the delay.  It would be interesting to see what
> the task manager says is happening during this time.  Does ls spike the
> CPU?

Yes it does, but only for directories with quite a number of files.   For example, I run ls -l under the /bin directory and the CPU
usage increased to 70 percent at that instant.   When I run it under teh C:\wiinnt\system32 directory, the CPU spiked to 100%,
fluctuating between 70% to 100% at the time of the delay in ls.

There has been reference to my F:drive in the past messages:

If this woul be of any help, my F drive is a NTFS file system.

Thanks a lot!

Best Regards,

Carlo Florendo
Astra Philippines, Inc.

Attachment: cygcheck.txt
Description: Text document

Attachment: strace.txt
Description: Text document

Unsubscribe info:
Problem reports:

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