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

Christopher Faylor
Wed Sep 29 15:10:00 GMT 2010

On Wed, Sep 29, 2010 at 11:08:21AM +0200, Derry Shribman wrote:
> >> Doesn't the 'noacl' mount option provide that already?
> >
> > Partially, there are also the ihash and the exec/notexec options.  A lot
> > has been already discussed on the cygwin-patches list, see, for instance
>The problem with mount options is that they are 'static'. They require a cygwin 
>'reboot' and they do not allow 'inheritance' for subprocesses, and do not allow 
>concurrent processes running in different modes.

Right.  Another way of looking at this is that the mount options offer
consistency.  The notion of setting an environment variable in Window A
to get one behavior and not settting it in Window B is, IMO, a support
nightmare and a recipe for end-user confusion.

>Dynamic options via CYGWIN env allow setting stuff in runtime, in /etc/profile, 
>~/bashrc, or for specific commands (and their subprocesses), such as:
>CYGWIN=no_nlink rsync c:/... z:/...
>This allows the user to be free to decide where to relax POSIX compliance in 
>order to achieve speed.
>It also allows application developers (such as 'git'), to decide in their code 
>how they want Cygwin to behave.
>In 'git' for example, it does need stat's nlink (number of hard links), and 
>actually, not even n_ino (the inode number). Cygwin's git performance was 
>ultra-slow, and they improved it by not using Cygwin's stat(), rather 
>re-implementing their own 'quick-stat' which worked directly with Win32 API.
>If Cygwin would have supported dynamic options (as opposed to mount time 
>options), instead of the large 'ifdef __CYGWIN__' code, it would simply be 
>adding 'setenv("CYGWIN", "no_nlink no_inode")' to the code in git's main().

Or, another way of looking at this is, instead of implementing their own
potentially buggy, imprecise stat() they could have not thought of
Cygwin as a black box and either 1) offered improvements for the DLL or
2) engaged the Cygwin community with requirements.  If there is ifdef'ed
__CYGWIN__ code in git now that means that any performance improvements that
we (i.e., Corinna) has made will never be noticed and that code will be
maintained forever.

>This allow applications to declare they will never look into the 'st_ino' and 
>'st_nlink'. The authors of an application, at the time of writing it, know 
>whether their code accesses these fields or not.

So, you're trading ifdef __CYGWIN__ in git with lots of if's in the very
parts of Cygwin code path where people complain about slowness.

But, anyway, if we were going to implement something like this, it wouldn't
be with environment variables, it would be with the proposed api that Eric
Blake has mentioned in the past.


More information about the Cygwin-developers mailing list