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
_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
