Yes, in some cases it does improve performance.
By default find
applies logical AND to its tests but the latter test is not evaluated if the former is false. So if you add a super fast test which almost always fails at the very beginning then it can save many executions of following (say: slow) tests and in this case this additional test does improve performance.
Go to directory with many files and few symlinks. Compare
time find -exec test -L {} \; -print
to
time find -type l -exec test -L {} \; -print
This is artificial yet enlightening example. The two tests (-type l
and -exec test -L {} \;
) do the same job, the two find
commands yield the same results. However -exec
creates additional process and this is relatively slow. In my home directory the first command takes two minutes; the second command takes six seconds.
(1) Good point. I (obviously) didn’t consider the case of
-type
being followed by slower tests (since the question didn’t suggest that that was going to happen, but I should have thought of it anyway). (2) What is thistype
program that you’re running? I getfind: ‘type’: No such file or directory
. – G-Man Says 'Reinstate Monica' – 2017-09-20T20:24:24.9701@G-Man Oops. I meant
test
; in my console I runtest
. Mindless mistake here. Should be OK now. – Kamil Maciorowski – 2017-09-20T20:45:34.657@KamilMaciorowski I don't know about the internal mechanism. honestly, I hoped it uses file table or other file system meta-data to speed up the search process but looks like it just traverse the directory structure as Jim Dennis mentioned here.
– Ali Ghanavatian – 2017-09-21T06:07:20.3901@AliQanavatian What is your point? All I'm saying is: if the first test fails then the rest is not evaluated at all; so you can speed things up sometimes thanks to additional test, even if it doesn't change the final output. – Kamil Maciorowski – 2017-09-21T06:16:40.853