Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
Derry Shribman
derry@hola.org
Thu Oct 7 15:39:00 GMT 2010
Hi,
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.
Derry
More information about the Cygwin-developers
mailing list