This is the mail archive of the cygwin 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: Slow directory listing


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/


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