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,

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


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