Re: NT directory traversal speed on 25K files on Cygwin
- From
- Rutger Nijlunsing <rutger@nospam.com>
- Date
- Feb 27, 2006, 18:30 UTC
- Message-ID
- <20060227183049.GA13195@nospam.com>
- In-Reply-To
- <20060227011801.GB9264@trixie.casa.cgf.cx>
On Sun, Feb 26, 2006 at 08:18:01PM -0500, Christopher Faylor wrote:
Show 41 quoted lines
> On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote: > >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote: > >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote: > >>>filesystem is slow and locked down, and exec-attribute is NOT really > >>>useful even on NTFS (it is somehow related to execute permission and > >>>open files. I still cannot figure out how exactly are they related). > >> > >>Again, it's not clear if you're talking about Windows or Cygwin but > >>under Cygwin, in the default configuration, the exec attribute means > >>the same thing to cygwin as it does to linux. > > > >I don't know about native Windows speed, but comparing NutCracker with > >Cygwin on a simple 'find . | wc -l' already gives a clue that looking > >at Cygwin to benchmark NT file inspection IO will give a skewed > >picture: > > > >##### NutCracker $ time find . | wc -l > > > >real 0m 1.44s > >user 0m 0.45s > >sys 0m 0.98s > >25794 > > > >##### Cygwin $ time c:\\cygwin\\bin\\find . | wc -l > > > >real 0m 6.72s > >user 0m 1.09s > >sys 0m 5.59s > >25794 > > > >##### CMD.EXE + DIR /S C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s > >>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata > >6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps > > > >##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\PROJECT> > >c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l 2.79user 7.81system > >0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794 > > I'm lost. What does this have to do with the exec attribute? > > Or, were you just climbing aboard the "Cygwin sure is slow" bandwagon?
I tried to get on the bandwagon 'NT file IO magnitudes slower => git magnitudes slower', but missed the parade a week ago. Then another parade showed up, but I managed to delete most of it with a misfortunate shift-something in mutt... And then even messed up in keeping the wrong paragraph... *hmpf*
However, the point I was trying to make was that git might be sped up by a magnitude (although not all of the magnitudes in comparison to Linux) by looking at why the file IO is this slow: Windows' file IO is _not_ the only reason. Using a different/new/better fitted interface to Cygwin or Win32 for a specific git task might help, although I have no clue what or how.
-- Rutger Nijlunsing ---------------------------------- eludias ed dse.nl never attribute to a conspiracy which can be explained by incompetence ----------------------------------------------------------------------