This is the mail archive of the cygwin 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: bash completion slow


Hi Eric,

Thanks for the reply.

The triple stat() issue I am talking about is a thread/patch that I read
from the 2002 timeframe.  I don't think the patch got integrated back tho.
http://sourceware.org/ml/cygwin/2002-05/msg01600.html
There was another thread that I can't find right now.

Actually Linux readdir doesn't provide any clues about the file either, it
returns the dirent structure.

However, this really opens my eyes as to the problem :

> operations, the result of which is just discarded).  With directories in
> particular, part of the slowdown is that stat()'s st_nlink field is
> populated by counting how many files appear in that sub-directory, even
> though readline didn't care about that.

I had the same issue with a tab in /cygdrive/c/ (obviously due to the
nasty-ness of the Windows directory).  My directory of 300 subdirectories
has umpteen files in the subdirectories.

What about turning this subdirectory parsing off by feeding a -1 in
st_nlink in Cygwin?  How could I propose such a change for cygwin?

Thanks again


> According to Christopher Wingert on 3/25/2007 8:35 AM:
> > Hi
> >
> > I have a directory where there are about 300 subdirectories in it. 
When I
> > hit tab, not only is the delay to the "Display all 300 possibilities..."
> > is slow but the screw draw after answer y is almost like a 300 baud
modem.
> >  I've read on these lists about the triple stat issue with cygwin, is
this
> > the cause of this problem?  Any solution to this problem?

> What 'triple stat' issue are you referring to?  Part of the problem is
> that tab completion relies on determining file type (directory vs. regular
> file, etc.), but unlike Linux, cygwin readdir() does not convey file type
> (because it is a relatively expensive operation for some file types, such
> as symlinks vs. block and character devices, involving opening the file,
> which would penalize readdir for other cases), while stat() conveys more
> information than readline cares about (involving even MORE expensive
> operations, the result of which is just discarded).  With directories in
> particular, part of the slowdown is that stat()'s st_nlink field is
> populated by counting how many files appear in that sub-directory, even
> though readline didn't care about that.  And part of the problem is that
> Windows just STINKS at enumerating directory contents.  Overall, it means
> that where there are 300 subdirectories, and readline is stat()ing all 300
> of them, cygwin ends up using Windows slow traversal of all 300
> directories.

> If readdir were to provide d_type in struct dirent, even populating it
> only with DT_DIR vs. DT_UNKNOWN, then readline's tab completion and
> several of the coreutils would gain some speedups, merely by being able to
> distinguish directories from other files without having to stat()
> directories.  But SHTDI and write such a patch, and prove that it doesn't
> penalize other uses of readdir that could care less about file type.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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