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...


Corinna

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