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: findutils support in 1.7.0


On Apr 28 10:39, Lev Bishop wrote:
> On Mon, Apr 28, 2008 at 9:04 AM, Corinna Vinschen wrote:
> > On Apr 28 14:13, Corinna Vinschen wrote:
> >  > but that's something I will have to test first.  I guess you will be
> >  > surprised to read that now, but I'm slightly disappointed at Windows...
> >
> >  I stick to being disappointed.  None of the above workarounds is any
> >  faster.  NT's path handling is obviously only designed for paths of up
> >  to MAX_PATH length.
> 
> Sorry if this is an irrelevant or trivial comment, but did you try
> using the RootDirectory element of ObjectAttributes? Ie, not giving
> the whole path to Nt...File(), instead descending the directory tree
> one (or a few) steps at a time? Perhaps that would be linear-time?

That's not possible right now and if so, it's only possible for relative
pathnames.  Eric's testcase would allow that, but the central path_conv
routine in Cygwin does not deal with directory handle relative paths so
far, rather it always creates a full path and uses that.

However, it's still strange that the path length (number of subdirs?)
goes quadratic into the timing behaviour of a core OS routine to access
a file.  The potential regression function evaluated by OpenOffice Calc
is

            5/3
  pathlength
  ------------- usecs
      100

and it appears to be a bit forgiving.


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]