Cygwin Performance and stat()

[Christopher Faylor]

On Sun, May 30, 2010 at 11:52:45PM +0200, Christian Franke wrote:
>Christopher Faylor wrote:
>> On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
>>    
>>> I assume POSIX compatibility.  However, I bet there are cases where one
>>> can sacrifice compatibility for performance (configurable with an
>>> environment flag of course).
>>>
>>>      
>
>The problem is that POSIX stat() requires to provide all information in 
>struct stat. This is expensive: convert ACL into mode, convert filetimes 
>into time_t, lookup uids, invent ino, ....
>Typically applications don't need all info but there is no way to tell 
>this to stat().
>
>>> See
>>>
>>> http://marc.info/?l=git&m=122278284210941
>>>
>>> for an example.
>>>      
>> Yes, I got what you meant.  I think that bypassing Cygwin, assuming you
>> can do something good enough is a remarkably bad idea.
>
>A probably better idea would be to add another stat() variant (this is 
>IMO missing in POSIX) to Cygwin which allows to specify which info is 
>needed.
>
>Something like:
>
>enum {
>   CYGSTAT_MODE = 0x01,
>   CYGSTAT_INO = 0x02,
>   CYGSTAT_SIZE = 0x04,
>   CYGSTAT_ATIME = 0x08,
>   ...
>};
>
>int cygwin_stat4(const char *path, struct stat *buf, unsigned needed, 
>unsigned *pvalid);
>
>Where 'needed' contains all CYGSTAT_* flags for the stat fields needed. 
>If 'pvalid' is != 0, the flags for the valid fields are returned in the 
>variable. This can be a superset of 'needed' if some info is available 
>for free.
>
>Usage example:
>
>// Get st_size only.
>#ifdef __CYGWIN__
>#define stat_size(p, b) cygwin_stat4(p, b, CYGSTAT_SIZE, NULL)
>#else
>#define stat_size(p, b) stat(p, b)
>#endif

And then you'd have to demonstrate that such an implementation actually
showed a measurable improvement, that it doesn't impact the existing
stat(), and that it would actually be used.

And, of course, as soon as you start talking about implementing
something non-POSIX you have strayed away from the whole point of
Cygwin.

And, also of course, we can get one new idea per message here in the
cygwin mailing list but that doesn't actually cause anything to be
implemented.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple