Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

[Derry Shribman]

Hi,

 > I think you just proved why a global setting is bad.  You are apparently
 > presupposing that libxxx.so is doing something that would be ok with a
 > "fast stat".  I don't see how you can ever make that assumption.  For

Every program author knows very well whether ino/nlink is required by his 
programs or libraries his programs uses.

libraries dont just do stuff on their own. Libraries do what the program 
requests them to do, so the program author knows whether they are doing 
something that night need ino/nlink.

cvs, gnumake, grep and many many others do not need ino/nlink, since ino/nlink 
is not related to the programs logic, and if any library they use IS using 
ino/nlink info, then its a very strange library, if not even a bug.

all the common libraries (libc, libnss, libz etc...) do not use ino/nlink on 
their own.

Beyond that: it has already been tested: many people mount with ihash (which 
means no ino/nlink), and nearly all the applications work without any problem.

Derry

On 9/30/2010 2:04 AM, Christopher Faylor wrote:
> On Wed, Sep 29, 2010 at 10:31:54PM +0200, Derry Shribman wrote:
>> Hi,
>>
>>> If it's known that the application doesn't ever use the "heavy" parts of
>>> stat() in any of its code, then substituting xstat() for stat() globally
>>> only needs to happen once in the code as well.
>>
>> It needs to be replaced in the following places:
>> - detection code added in autoconf
>> - define in a header
>> #ifdef HAVE_XSTAT
>> #define STRUCT_FAST_STAT struct xstat
>> #define FAST_STAT(...) xstat(__VA_ARGS__)
>> #else
>> #define STRUCT_FAST_STAT struct stat
>> #define FAST_STAT(...) stat(__VA_ARGS__)
>> #endif
>>
>> And now need to search/replace in every single file where 'struct stat' and
>> 'stat()' appear to change them to STRUCT_FAST_STAT, and FAST_STAT()
>>
>> This is a BIG change.
>>
>> And the problem is that it does not have a GLOBAL effect on the program. It only
>> affects the code compiled directly, not the code linked together with the
>> application. So if a program uses libraries (/lib/libxxx.a or /lib/libxxx.so),
>> the above will not affect the libs the program uses.
>
> I think you just proved why a global setting is bad.  You are apparently
> presupposing that libxxx.so is doing something that would be ok with a
> "fast stat".  I don't see how you can ever make that assumption.  For
> instance, if your application is using ncurses how can you know for
> certain that it doesn't ever need to real inode numbers?  You have no
> idea what all of the libraries you're linking with could be using.
>
> cf
>
>