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,

> 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




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