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

Derry Shribman
Thu Oct 7 15:39:00 GMT 2010


On 10/7/2010 5:09 PM, Corinna Vinschen wrote:
> On Oct  7 16:54, Derry Shribman wrote:
>> Yet another possible improvement on this line that could be
>> implemented in the future after the fs_info caching is added:
>> We see that reading actual DATA from a file REALLY slow: on Windows
>> with AV its slow due to the AV scanning the file, and on Network
>> Shares (Samba/NFS) - it means create-read-close (3 round-trips) - as
>> opposed to network-open-info (1 round-trip).
>> Cygwin reads file content for symlinks (!<symlink>) and files that
>> may be executable (#!/bin/xxx magic).
>> A cache could be added for this using the same cache mechanism. The
>> cache-validation can be done with the quick QAF() (or QIF/QDF), and
>> then the read the potential symlink/executable file's header only if
>> needed.
> I'm wondering if that really is such a big problem.  It depends how
> often a symlink is accessed.  This might be worth to consider for
> symlinks to directories, but it's probably not noticable for symlinks to
> files.  Anyway, yes, we can try that at one point.

Example for directory symlink that can make significant performance problem:
If someone sets /home as a symlink, then anything he runs inside his home 
directory will work slowly.

Example for file symlink that can make significant performance problem:
Inside /bin there are many many symlinks. Cygwin's tab completion takes around 
3(!) full seconds on my PC due to this.


More information about the Cygwin-developers mailing list