Why is find so slow (Re: Why use find?)
Chris Torek
chris at mimsy.umd.edu
Wed Oct 10 14:39:21 AEST 1990
In article <F6.rhxm2 at cs.psu.edu> flee at guardian.cs.psu.edu (Felix Lee) writes:
>"descend" is fast because it recognizes leaf directories and avoids
>stat()ing the files in that directory. This is usually a big win,
>since most files tend to be in leaf directories.
>
>"find" can't do this in general, since most of its predicates require
>stat()ing each file, but it wouldn't be too hard to add lazy stat()ing
>to find. And it may even be worth it.
Quite likely.
4.3BSD-reno's `find' reimplementation (a redistributable version) uses
the C library `fts' routines (from POSIX) which take flags indicating
whether `stat's are desired. If you say `no', it stats only when this
is required to search the directory. The new find sets the `I need
stat information' only when at least one predicate requires it. The
result:
% cd /usr/src/local/games
% time find . name obj
./umoria/obj
0.3u 0.8s 0:01 91% 35+56k 0+0io 2pf+0w
% time find . type l
./umoria/obj
0.5u 5.2s 0:09 63% 42+66k 94+1io 3pf+0w
%
It makes a pretty big difference. If find said `no stat' and did the
stats only when some predicate actually required it, that would help
make things like
find . \( name foo or name bar \) and type l
run much faster. Uncommon? Not really:
find / \( fstype local or prune \) \( \
\( name '[#,]*' atime +1 \) \
or \( \( name '*.bak' or name '.*.bak' \) atime +3 \) \
or \( name '.emacs_[0-9]*' atime +7 \) \
or \( name core \) \
\) print exec /bin/rm -f {} \;
Incidentally, yes, find still accepts the old syntax (find . -name ...).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain: chris at cs.umd.edu Path: uunet!mimsy!chris
More information about the Comp.unix.internals
mailing list