This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]