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

[Derry Shribman]

Hi,

The question splits up to two parts:

Q) how can you know for sure a specific application does not use ino/nlink.
A) answer: grep -rs '\<st_ino\|st_nlink\>' .
    long answer: the developer and the power-users of that application normally 
know it due to the way that application works. For example: I am a long time 
user of cvs, gnumake. I know they do no use ino/nlink specific info. I am sure 
also their authors know that...

Q) how much code needs to be modified to get this to work?
A) just add
#ifdef __CYGWIN__
     setenv("CYGWIN", "no_ino no_nlink");
#endif
In the code. ONCE!

On the other hand, according to your xstat() suggestion, you need to modify 
every single stat() call:

func()
{
     struct stat st;
     ...
     ret = stat(file, &st);

To:
func()
{
#ifdef HAVE_XSTAT
     struct xstat st;
#else
     struct stat st;
#endif
     ...
#ifdef HAVE_XSTAT
     ret = xstat(file, &st);
#else
     ret = stat(file, &st);
#endif

Also: every 'struct stat' member inside a structure, and every single 'struct 
stat' function argument etc etc.

It also requires autoconf to detect HAVE_XSTAT.

Also: implementing CYGWIN env today does not prohibit cygwin supporting xstat() 
in the future.

Derry

On 9/29/2010 8:49 PM, Larry Hall (Cygwin Developers) wrote:
> On 9/29/2010 2:29 PM, Derry Shribman wrote:
>> Hi,
>>
>> xstat() is a new Linux system call that allows a user-mode application to
>> specifically request more (or less) stat information.
>>
>> Since this is a new Linux API, it requires porting for existing Unix
>> application to replace every single stat() calls in their code to xstat() in
>> order to benefit from this API.
>>
>> This is quite a big change in the code - and application maintainers will not
>> rush to change their code until this new Linux kernels with this API are
>> commonly installed.
>>
>> So it does not fit what Cygwin needs because: 1) it requires a lot of change
>> to existing code of every single application. 2) it will take many years
>> until it will be available on most of the installed Linux kernel images.
>
> OK, so if we accept that as a premise for the sake of argument, why would
> application developers be more inclined to support a Cygwin-specific solution
> to this problem than they would a portable one? Every existing usage of
> stat() still needs to be inspected before any solution is implemented at
> the application level.
>