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


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]