Re: performance issue with cgywin make

[Bill Hoffman]

Bill Hoffman wrote:
> Christopher Faylor wrote:
> > > Thanks.
> > >     
> >
> > Why should the msvcrt _stat be slow?  I wouldn't assume that to be 
> > the case.
> >   
> We did not assume it would be slow either.  However, at some point we 
> made the change in
> cmake because we found that much of the run time on windows was spent 
> in stat, and that linux
> stat times were a much smaller part of the run time.  I do not 
> remember the exact numbers, but
> I do remember it being a significant speed up, 2 to 3 times faster.   
> I will see if I can create a test
> case that uses both.  The only thing I can figure is that the stat 
> call may do some sort of memory allocation
> and copy to get from the native windows structures to the POSIX's 
> structure. 
> -Bill
I did a bit of google searching and found this:

http://lists.freedesktop.org/archives/fontconfig/2006-September/002477.html

/* Workaround for problems in the stat() in the Microsoft C library:
+ *
+ * 1) stat() uses FindFirstFile() to get the file or directory
+ * attributes. Unfortunately this API doesn't return correct values
+ * for modification time of a directory until some time after a file
+ * or subdirectory has been added to the directory. (This causes
+ * run-test.sh to fail, for instance.) GetFileAttributesEx() is
+ * better, it returns the updated timestamp right away.
+ *
+ * 2) stat() does some very strange crap related to backward
+ * compatibility with the local time timestamps on FAT volumes and
+ * daylight saving time. This causes problems after the switches
+ * to/from daylight saving time. See
+ * http://bugzilla.gnome.org/show_bug.cgi?id=154968 , especially
+ * comment #30, and http://www.codeproject.com/datetime/dstbugs.asp .
+ * We don't need any of that crap, just use the UTC timestamps
+ * from NTFS, converted to the Unix epoch.
+ */

So it would seem that stat calls FindFirstFile, but GetFileAttributesEx 
is a direct single call.

-Bill