incredibly slow file listing script on windoze 7 pro 4 core 64 bit

Eric Blake
Wed Sep 8 15:59:00 GMT 2010

On 09/08/2010 09:24 AM, Larry Hall (Cygwin) wrote:
> To somewhat sooth your curiousity, Windows (or perhaps it's more accurate
> to say NTFS) ain't great with directories with a large number of files.
> I expect you would be less than impressed with the performance of of 'dir'
> in 'cmd.exe' in the same directory. That said, you're asking for allot more
> work than you may realize when doing the same thing in Cygwin. In order to
> fill in the information you ask for when you use the '-l' flag for 'ls',
> Cygwin needs to open and close the files, which takes a good chunk of time
> en masse. The same does not need to happen in Linux/UNIX-land.

Additionally, the stat() interface is puny - it MUST take the time to 
fill out the complete struct, even if the caller only cares for part of 
the information.  If the Linux kernel ever incorporates the pending 
xstat() kernel call[1], then cygwin adds support for it, and coreutils 
is taught to make good use of it, then operations like ls can be sped up 
by asking for only the portions of the stat data that they plan on 
actually using, letting cygwin skip the work of obtaining the rest of 
the stat information just to be thrown away by the caller.

[1]version 6 of that kernel patch is still being debated; as recently as

Eric Blake    +1-801-349-2682
Libvirt virtualization library

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list