[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: performance issue with cgywin make

From: Bill Hoffman
Subject: Re: performance issue with cgywin make
Date: Thu, 07 Dec 2006 23:20:22 -0500
User-agent: Thunderbird (Windows/20061025)

Bill Hoffman wrote:
Christopher Faylor wrote:


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:

/* 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
+ * 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
+ * , especially
+ * comment #30, and .
+ * 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]