On 9/8/10, Eric Blake <ebl...@russianhut.comie> wrote: > 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
I don't want to add more clutter with this contrived example but just to make a point, I just got a 500G WD USB disk and sent these things to their final resting place. I had to reformat it is as vfat as that seems to be the only thing that is RW everywhere. I ran the script on this newer debian install with vfat and USB disk and it is faster than 'doze and probably faster than old emachines because I now have 2.8ghz CPU LOL. >> 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 > http://lkml.indiana.edu/hypermail/linux/kernel/1008.2/00274.html > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
