Re: src/winsup/cygwin ChangeLog fhandler_proc.cc f ...

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

On Oct  9 18:22, Corinna Vinschen wrote:
> On Oct  9 09:07, Eric Blake wrote:
> > On 10/09/2014 08:51 AM, Corinna Vinschen wrote:
> > >> The whole point of d_type is for optimization, to tell a process when it
> > >> can avoid the overhead of an lstat() because the system was able to
> > >> obtain the information in a cheaper manner.  But if you have to resort
> > >> to an lstat() to get the information, then you are wasting cycles on the
> > >> case of a user that doesn't care about d_type.  I'd rather we always
> > >> return DT_UNKNOWN if the only way we'd get a better type is by calling
> > >> lstat().
> > > 
> > > I see.  The idea here was to try and, at least on my machine, it
> > > was still *very* fast, likely because the whole thing occurs only
> > > in globally allocated memory and there's no disk access or paging
> > > involved.
> > > 
> > > The question is, what exactly do we lose?  /proc/sys isn't often
> > > accessed at all (I guess) and what could be gained?  Yaakov asked
> > > for setting d_type under /proc, so he might enlighten us which
> > > tools make heavy use of the stuff, so the net gain is > 0...
> > 
> > Some modes of 'find' and 'ls' (such as ls -F) are faster if d_type is
> > accurate (because they avoided an lstat); there, returning DT_UNKNOWN
> > requires the lstat.  In other cases (like ls -l) an lstat is always
> > required.  Anywhere that lstat is slow, embedding an lstat into d_type
> > determination as well as a followup lstat is going to make directory
> > traversal twice as slow (well, maybe the second call is faster because
> > of caching effects); conversely, anywhere that lstat is not required by
> > the caller, it is wasted effort during the readdir.  But as you say,
> > lstat in /proc/sys is mostly stuff in memory and already fast, so maybe
> > it doesn't hurt to leave it in.
> 
> I made a quick test on 64 bit W8.1 and a non-opimized Cygwin DLL.
> 
>   time ls -l --color=always /proc/sys/Device/
> 
> takes a constant 0.53 secs without my patch, and a constant 0.83 secs
> with my patch.  So it's actually rather noticable, being more than 50%
> slower.  It's hard to justify such a hit...

I applied another technique which has no noticable performance hit.  It
doesn't recognize all objects, only directories, symlinks, and partially
character devices, but on the upside it uses only information which has
already been provided anyway.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]