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


On Oct  7 14:33, Yoni Londner wrote:
> Upside: 10x faster than 1.7.8 unpatched. 25% faster than QIF patch.
> Downside: does not retrieve st_nlink (but its not that of a problem,
> since usage of st_nlink in applicates is very rate, and its
> controllable via CYGWIN=xstat, and its by default off (to keep
> compatibility))

You're missing the missing permissions.  That's a very big downside in
my book.  And you're missing the fact that the code is slower than QIF
on NFS.  That's maybe not much of a problem for you, but it is for us.
But see below.

> So - attached is the MERGE patch (xstat+QIF) which brings the best
> of both worlds :-)

I don't want to apply the xcheck patch as is and not right now.  Please
let me go into vacation first.  We can discuss this further second half
of November if you don't mind.

Ok, here's one for the records.

In your original patch on the cygwin-patches ML you implemented the
fs_info caching using the pathname.  I still don't think this is correct
for the reasons given in another mail.  However, maybe we can use it
nevertheless like this:

- If we don't find a path prefix matching the incoming path, call
  symlink_info::check.

- Otherwise we have a cached fs_info for the path prefix:

  - If the path is NFS, call check.
  - Otherwise, if the calling function doesn't need st_nlink or st_mode,
    call xcheck.
  - Otherwise, call check.

- In check and xcheck, always fetch fs_info using the current method.
  Write back to path-based cache so we use the info the next time
  around.

This way we have potentially a slow access for the first file, but
a matching, fast access for subsequent files.  By always renewing
the fs_info and using the volume info based cache, we don't rely
on the pathname being fixed.  And we always have a correct fs_info in
path_conv and a high probability to use the fastest matching check
routine.
Additionally we can utilize the fact that junction points only work
for local drives.  That allows to skip the test for a junction for
all remote drives.

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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