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:34:00 GMT 2010


Hi,

On 10/7/2010 3:45 PM, Corinna Vinschen wrote:
 > Well, just an idea.  I'm also still mulling over a good caching
 > method to speed up `ls -l'.  The worst problem is still that `ls -l'
 > calls getacl on all files.  In case of using POSIX permissions (default
 > "acl" mount), this potentially requires to open all files three times.
 > Since we already have the ACL from the lstat call, it's kind of a pity
 > that we don't reuse it in the subsequent getacl calls.

May a 'generic cygwin cache' cound be added later on, for caching paths to 
'extra cygwin/POSIX info' (st_nlink, st_ino, ACL, symlink magic, exectuable 
magic, filesystem info).

This cache found be shared by fs_info and lstat/xstat, scandir and others.

The cache re-validation could be perhaps something like QAF().

And once working, this cache could be in the future even upgraded to use 
shared-memory section, which would make this cache available for all cygwin 
processes.

Such an implementation could allow near native Win32 speed while giving full 
POSIX support - so the cygwin user will not need to choose between acl/nlink/etc 
features vs. security - rather he could have them all.

VMWARE did very good work on providing near native performance in a hash 
envirnoment (non virtualization friendly x86 CPU, and non virtualization 
friendly Windows OS). They did it with smart implementation tricks around the 
hot-spots, and using caching where needed.
I checked what VMWARE did with hgfs (host filesystem): and saw they cached in 
user-mode some of the filesystem info.
So if such a caching technique is good for vmware - it could also be beneficial 
for cygwin.

Derry



More information about the Cygwin-developers mailing list