On Sun, Feb 26, 2006 at 08:18:01PM -0500, Christopher Faylor wrote: > 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 ---------------------------------------------------------------------- - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html