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: Performance of "ls -F"

On Jan 25 11:02, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at>> writes:
> > In the noacl case, Cygwin tries to find out if files are scripts.  It
> > opens the file and checks the first two bytes in the file for a shebang
> > (and other stuff).
> acl > time ls --file-type > /dev/null
> 0.015u 0.015s 0:00.42 4.7%      0+0k 0+0io 2473pf+0w
> acl > time ls -F > /dev/null
> 0.078u 0.858s 1:10.69 1.3%      0+0k 0+0io 5243pf+0w
> noacl > time ls --file-type > /dev/null
> 0.015u 0.015s 0:00.37 5.4%      0+0k 0+0io 2391pf+0w
> noacl > time ls -F > /dev/null
> 0.093u 1.327s 1:38.90 1.4%      0+0k 0+0io 6309pf+0w
> >  This may take a lot of time, more so on network
> > drives.  Can you try adding the "notexec" mount option to the "noacl"
> > share and see if that helps?
> acl,notexec > time ls --file-type > /dev/null
> 0.015u 0.030s 0:00.41 9.7%      0+0k 0+0io 2471pf+0w
> acl,noexec > time ls -F > /dev/null
> 0.062u 0.811s 1:10.31 1.2%      0+0k 0+0io 5240pf+0w
> noacl,notexec > time ls --file-type > /dev/null
> 0.031u 0.030s 0:00.41 14.6%     0+0k 0+0io 2389pf+0w
> noacl,notexec > time ls -F > /dev/null
> 0.046u 0.718s 0:56.23 1.3%      0+0k 0+0io 4994pf+0w
> > This test is done for a looong time to accommodate FAT filesystems in
> > the first place.  It might be prudent to disable it by default these
> > days...
> Looks like that's not the main reason for the extra time spent.

Off the top of my head, the common denominator seems to be that on
directories returning d_type information, --file-type doesn't have to
call stat().  That makes it very fast since only a directory enumeration
is done.  Calling stat on the other hand is time consuming since on
Windows it requires to open the file and read meta information (including
the ACL) or data (noacl exe recognition) from it.

> Here's another NetApp share, but this time there are about half as many
> files with only two of them in each sub-directory.
> (1046)/mnt/upload/install > time ls --file-type x86*/patches/*/* > /dev/null
> 0.155u 1.358s 0:09.42 15.9%     0+0k 0+0io 10555pf+0w
> (1047)/mnt/upload/install > time ls -F x86*/patches/*/* > /dev/null
> 0.109u 1.046s 0:08.20 13.9%     0+0k 0+0io 9817pf+0w
> Somehow that takes a lot less time and there's no difference between the two
> invocations (or actually a bit less time for -F).  The getVolInfo helper
> sees these two shares with the same settings.  Not sure what to make of that...

Hmm, no, sorry, I have no idea.  Somebody will have to debug this.


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

Attachment: signature.asc
Description: PGP signature

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