Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
Thu Oct 7 15:34:00 GMT 2010
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
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
More information about the Cygwin-developers