X-Spam-Check-By: sourceware.org
Message-ID: <468D5C08.A5655011@dessent.net>
Date: Thu, 05 Jul 2007 14:00:56 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Slow directory listing
References: <F9DBA559074DDB41BDD51E9681001BC88C270F AT Deliverance DOT voxify DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Anton Ivanov wrote:

> As I said the directory for which the listing takes a long time to
> produce contains only 22 entries.
> I tried 'ls', not 'ls -l'.

Note that sometimes even plain 'ls' requires a full stat call on each
file, such as if you have coloring enabled via an alias or for the
printing a trailing / or * after directories and executables.  You can
type e.g. "l\s -f" to eliminate these factors, and if it's much faster
than a plain "ls" that's probably part of the explanation.

> Are you saying that in order to construct a 'stat' structure for a
> directory, cygwin must examine the contents of subdirectories?
> This sounds too strange to believe.  Which fields of 'stat' in
> particular require this?  Why is it that listing '/' is not at all slow?

I don't think Cygwin has to explicitly traverse the contents of the
subdirectories, but it does still have to individually open each
directory entry and call GetFileInformationByHandle() (or equivalent) in
order to populate fields such as st_nlink, and for large directories
windows itself might take a long time to process this request.  Note
that link count implicitly includes as a minimum a count of the number
of sub-subdirectories, since the directory entry '..' in 'foo/bar' is a
hard link to 'foo', in addition to any explicit hard links that might
also be present.  I don't know whether this link count is stored
pre-computed by NTFS or not, so this may be a red herring.

You can see what's going on in more detail with strace and/or
sysinternals' filemon.

> It still appears to me that in my particular case the slow-down is not
> necessary.

To pronounce that it's not necessary requires that you first determine
what precisely Cygwin is doing and can then provide a reasoned argument
as to why these actions are extraneous.  I realize that it's annoying
when software takes longer than you expect to do something, but without
this analysis there's not much we can actually do other than confirm
that yes, Cygwin is by design slow in many circumstances.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/