Why is the command “find | grep 'filename'” so much slower than “ find 'filename' ”?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
8
down vote

favorite
2












I tried both commands and the command find | grep 'filename' is many many times slower than the simple find 'filename' command.



What would be a proper explanation for this behavior?










share|improve this question



















  • 2




    You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
    – Raman Sailopal
    Oct 3 '17 at 10:07










  • Slower in what sense? Does the commands take a different amount of time to complete?
    – Kusalananda
    Oct 3 '17 at 10:10






  • 1




    I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
    – Kusalananda
    Oct 3 '17 at 10:16







  • 2




    @JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
    – Kusalananda
    Oct 3 '17 at 10:30







  • 2




    Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
    – Kusalananda
    Oct 3 '17 at 10:51














up vote
8
down vote

favorite
2












I tried both commands and the command find | grep 'filename' is many many times slower than the simple find 'filename' command.



What would be a proper explanation for this behavior?










share|improve this question



















  • 2




    You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
    – Raman Sailopal
    Oct 3 '17 at 10:07










  • Slower in what sense? Does the commands take a different amount of time to complete?
    – Kusalananda
    Oct 3 '17 at 10:10






  • 1




    I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
    – Kusalananda
    Oct 3 '17 at 10:16







  • 2




    @JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
    – Kusalananda
    Oct 3 '17 at 10:30







  • 2




    Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
    – Kusalananda
    Oct 3 '17 at 10:51












up vote
8
down vote

favorite
2









up vote
8
down vote

favorite
2






2





I tried both commands and the command find | grep 'filename' is many many times slower than the simple find 'filename' command.



What would be a proper explanation for this behavior?










share|improve this question















I tried both commands and the command find | grep 'filename' is many many times slower than the simple find 'filename' command.



What would be a proper explanation for this behavior?







command-line grep find search file-search






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 3 '17 at 12:32









Hauke Laging

53.7k1282130




53.7k1282130










asked Oct 3 '17 at 10:04









yoyo_fun

322412




322412







  • 2




    You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
    – Raman Sailopal
    Oct 3 '17 at 10:07










  • Slower in what sense? Does the commands take a different amount of time to complete?
    – Kusalananda
    Oct 3 '17 at 10:10






  • 1




    I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
    – Kusalananda
    Oct 3 '17 at 10:16







  • 2




    @JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
    – Kusalananda
    Oct 3 '17 at 10:30







  • 2




    Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
    – Kusalananda
    Oct 3 '17 at 10:51












  • 2




    You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
    – Raman Sailopal
    Oct 3 '17 at 10:07










  • Slower in what sense? Does the commands take a different amount of time to complete?
    – Kusalananda
    Oct 3 '17 at 10:10






  • 1




    I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
    – Kusalananda
    Oct 3 '17 at 10:16







  • 2




    @JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
    – Kusalananda
    Oct 3 '17 at 10:30







  • 2




    Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
    – Kusalananda
    Oct 3 '17 at 10:51







2




2




You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
– Raman Sailopal
Oct 3 '17 at 10:07




You are listing every file with find and then passing the data to grep to process. With find used on it's own you are missing the step of passing every listed file to grep to parse the output. This will therefore be quicker.
– Raman Sailopal
Oct 3 '17 at 10:07












Slower in what sense? Does the commands take a different amount of time to complete?
– Kusalananda
Oct 3 '17 at 10:10




Slower in what sense? Does the commands take a different amount of time to complete?
– Kusalananda
Oct 3 '17 at 10:10




1




1




I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
– Kusalananda
Oct 3 '17 at 10:16





I can't reproduce this locally. If anything, time find "$HOME" -name '.profile' reports a longer time than time find "$HOME" | grep -F '.profile'. (17s vs. 12s).
– Kusalananda
Oct 3 '17 at 10:16





2




2




@JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
– Kusalananda
Oct 3 '17 at 10:30





@JenniferAnderson I ran both repeatedly. The 17 and 12 seconds are averages. And yes, the grep variation will match anywhere in the find result, whereas matching with find -name would only match exactly (in this case).
– Kusalananda
Oct 3 '17 at 10:30





2




2




Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
– Kusalananda
Oct 3 '17 at 10:51




Yes, find filename would be fast. I kinda assumed that this was a typo and that the OP meant find -name filename. With find filename, only filename would be examined (and nothing else).
– Kusalananda
Oct 3 '17 at 10:51










5 Answers
5






active

oldest

votes

















up vote
11
down vote













(I'm assuming GNU find here)



Using just



find filename


would be quick, because it would just return filename, or the names inside filename if it's a directory, or an error if that name did not exist in the current directory. It's a very quick operation, similar to ls filename (but recursive if filename is a directory).



In contrast,



find | grep filename


would allow find to generate a list of all names from the current directory and below, which grep would then filter. This would obviously be a much slower operation.



I'm assuming that what was actually intended was



find . -type f -name 'filename'


This would look for filename as the name of a regular file anywhere in the current directory or below.



This will be as quick (or comparably quick) as find | grep filename, but the grep solution would match filename against the full path of each found name, similarly to what -path '*filename*' would do with find.




The confusion comes from a misunderstanding of how find works.



The utility takes a number of paths and returns all names beneath these paths.



You may then restrict the returned names using various tests that may act on the filename, the path, the timestamp, the file size, the file type, etc.



When you say



find a b c


you ask find to list every name available under the three paths a, b and c. If these happens to be names of regular files in the current directory, then these will be returned. If any of them happens to be the name of a directory, then it will be returned along with all further names inside that directory.



When I do



find . -type f -name 'filename'


This generates a list of all names in the current directory (.) and below. Then it restricts the names to those of regular files, i.e. not directories etc., with -type f. Then there is a further restriction to names that matches filename using -name 'filename'. The string filename may be a filename globbing pattern, such as *.txt (just remember to quote it!).



Example:



The following seems to "find" the file called .profile in my home directory:



$ pwd
/home/kk
$ find .profile
.profile


But in fact, it just returns all names at the path .profile (there is only one name, and that is of this file).



Then I cd up one level and try again:



$ cd ..
$ pwd
/home
$ find .profile
find: .profile: No such file or directory


The find command can now not find any path called .profile.



However, if I get it to look at the current directory, and then restrict the returned names to only .profile, it finds it from there as well:



$ pwd
/home
$ find . -name '.profile'
./kk/.profile





share|improve this answer


















  • 1




    find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
    – Stéphane Chazelas
    Oct 3 '17 at 11:52

















up vote
0
down vote













Notice: I'll assume that you mean find . -name filename (otherwise, you're looking for different things; find filename actually looks into a path called filename, which might contain almost no files, hence exiting really quickly).




Suppose you have a directory holding five thousand files. On most filesystems, these files are actually stored in a tree structure, which allows to quickly locate any one given file.



So when you ask find to locate a file whose name only requires checking, find will ask for that file, and that file only, to the underlying filesystem, which will read very few pages from the mass storage. So if the filesystem is worth its salt, this operation will run much faster than traversing the whole tree to retrieve all entries.



When you ask for plain find however that's exactly what you do, you traverse the whole tree, reading. Every. Single. Entry. With large directories, this might be a problem (it's exactly the reason why several softwares, needing to store lots of files on disk, will create "directory trees" two or three components deep: this way, every single leaf only needs to hold fewer files).






share|improve this answer





























    up vote
    0
    down vote













    I have not understood the problem yet but can provide some more insights.



    Like for Kusalananda the find | grep call is clearly faster on my system which does not make much sense. At first I assumed some kind of buffering problem; that writing to the console slows down the time to the next syscall for reading the next file name. Writing to a pipe is very fast: about 40MiB/s even for 32-byte writes (on my rather slow system; 300 MiB/s for a block size of 1MiB). Thus I assumed that find can read from the file system faster when writing to a pipe (or file) so that the two operations reading file paths and writing to the console could run in parallel (which find as a single thread process cannot do on its own.



    It's find's fault



    Comparing the two calls



    :> time find "$HOME"/ -name '*.txt' >/dev/null

    real 0m0.965s
    user 0m0.532s
    sys 0m0.423s


    and



    :> time find "$HOME"/ >/dev/null

    real 0m0.653s
    user 0m0.242s
    sys 0m0.405s


    shows that find does something incredibly stupid (whatever that may be). It just turns out to be quite incompetent at executing -name '*.txt'.



    Might depend on the input / output ratio



    You might think that find -name wins if there is very little to write. But ist just gets more embarrassing for find. It loses even if there is nothing to write at all against 200K files (13M of pipe data) for grep:



    time find /usr -name lwevhewoivhol


    find can be as fast as grep, though



    It turns out that find's stupidity with name does not extend to other tests. Use a regex instead and the problem is gone:



    :> time find "$HOME"/ -regex '.txt$' >/dev/null 

    real 0m0.679s
    user 0m0.264s
    sys 0m0.410s


    I guess this can be considered a bug. Anyone willing to file a bug report? My version is find (GNU findutils) 4.6.0






    share|improve this answer






















    • How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
      – psmears
      Oct 3 '17 at 16:09










    • @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
      – Hauke Laging
      Oct 3 '17 at 18:24










    • Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
      – Barmar
      Oct 4 '17 at 18:01










    • @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
      – Hauke Laging
      Oct 5 '17 at 8:10










    • Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
      – Barmar
      Oct 5 '17 at 15:39

















    up vote
    0
    down vote













    Non-Technical explanation: Looking for Jack in a crowd is faster than looking for everyone in a crowd and eliminating all from consideration except Jack.






    share|improve this answer




















    • The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
      – Kusalananda
      Oct 4 '17 at 13:56


















    up vote
    -2
    down vote













    Lets assume the file /john/paul/george/ringo/beatles exists and the file you are searching for is called 'stones'



    find / stones


    find will compare 'beatles' to 'stones' and drop it when the 's' and 'b' don't match.



    find / | grep stones


    In this case find will pass '/john/paul/george/ringo/beatles' to grep and grep will have to work its way through the entire path before determining if its a match.



    grep is therefore doing far more work which is why it takes longer






    share|improve this answer
















    • 1




      Have you given that a try?
      – Hauke Laging
      Oct 3 '17 at 12:37






    • 3




      The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
      – Mat
      Oct 3 '17 at 12:44











    • grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
      – Paranoid
      Oct 3 '17 at 13:00










    • @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
      – pipe
      Oct 3 '17 at 19:11










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f395801%2fwhy-is-the-command-find-grep-filename-so-much-slower-than-find-filename%23new-answer', 'question_page');

    );

    Post as a guest






























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    11
    down vote













    (I'm assuming GNU find here)



    Using just



    find filename


    would be quick, because it would just return filename, or the names inside filename if it's a directory, or an error if that name did not exist in the current directory. It's a very quick operation, similar to ls filename (but recursive if filename is a directory).



    In contrast,



    find | grep filename


    would allow find to generate a list of all names from the current directory and below, which grep would then filter. This would obviously be a much slower operation.



    I'm assuming that what was actually intended was



    find . -type f -name 'filename'


    This would look for filename as the name of a regular file anywhere in the current directory or below.



    This will be as quick (or comparably quick) as find | grep filename, but the grep solution would match filename against the full path of each found name, similarly to what -path '*filename*' would do with find.




    The confusion comes from a misunderstanding of how find works.



    The utility takes a number of paths and returns all names beneath these paths.



    You may then restrict the returned names using various tests that may act on the filename, the path, the timestamp, the file size, the file type, etc.



    When you say



    find a b c


    you ask find to list every name available under the three paths a, b and c. If these happens to be names of regular files in the current directory, then these will be returned. If any of them happens to be the name of a directory, then it will be returned along with all further names inside that directory.



    When I do



    find . -type f -name 'filename'


    This generates a list of all names in the current directory (.) and below. Then it restricts the names to those of regular files, i.e. not directories etc., with -type f. Then there is a further restriction to names that matches filename using -name 'filename'. The string filename may be a filename globbing pattern, such as *.txt (just remember to quote it!).



    Example:



    The following seems to "find" the file called .profile in my home directory:



    $ pwd
    /home/kk
    $ find .profile
    .profile


    But in fact, it just returns all names at the path .profile (there is only one name, and that is of this file).



    Then I cd up one level and try again:



    $ cd ..
    $ pwd
    /home
    $ find .profile
    find: .profile: No such file or directory


    The find command can now not find any path called .profile.



    However, if I get it to look at the current directory, and then restrict the returned names to only .profile, it finds it from there as well:



    $ pwd
    /home
    $ find . -name '.profile'
    ./kk/.profile





    share|improve this answer


















    • 1




      find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
      – Stéphane Chazelas
      Oct 3 '17 at 11:52














    up vote
    11
    down vote













    (I'm assuming GNU find here)



    Using just



    find filename


    would be quick, because it would just return filename, or the names inside filename if it's a directory, or an error if that name did not exist in the current directory. It's a very quick operation, similar to ls filename (but recursive if filename is a directory).



    In contrast,



    find | grep filename


    would allow find to generate a list of all names from the current directory and below, which grep would then filter. This would obviously be a much slower operation.



    I'm assuming that what was actually intended was



    find . -type f -name 'filename'


    This would look for filename as the name of a regular file anywhere in the current directory or below.



    This will be as quick (or comparably quick) as find | grep filename, but the grep solution would match filename against the full path of each found name, similarly to what -path '*filename*' would do with find.




    The confusion comes from a misunderstanding of how find works.



    The utility takes a number of paths and returns all names beneath these paths.



    You may then restrict the returned names using various tests that may act on the filename, the path, the timestamp, the file size, the file type, etc.



    When you say



    find a b c


    you ask find to list every name available under the three paths a, b and c. If these happens to be names of regular files in the current directory, then these will be returned. If any of them happens to be the name of a directory, then it will be returned along with all further names inside that directory.



    When I do



    find . -type f -name 'filename'


    This generates a list of all names in the current directory (.) and below. Then it restricts the names to those of regular files, i.e. not directories etc., with -type f. Then there is a further restriction to names that matches filename using -name 'filename'. The string filename may be a filename globbing pattern, such as *.txt (just remember to quote it!).



    Example:



    The following seems to "find" the file called .profile in my home directory:



    $ pwd
    /home/kk
    $ find .profile
    .profile


    But in fact, it just returns all names at the path .profile (there is only one name, and that is of this file).



    Then I cd up one level and try again:



    $ cd ..
    $ pwd
    /home
    $ find .profile
    find: .profile: No such file or directory


    The find command can now not find any path called .profile.



    However, if I get it to look at the current directory, and then restrict the returned names to only .profile, it finds it from there as well:



    $ pwd
    /home
    $ find . -name '.profile'
    ./kk/.profile





    share|improve this answer


















    • 1




      find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
      – Stéphane Chazelas
      Oct 3 '17 at 11:52












    up vote
    11
    down vote










    up vote
    11
    down vote









    (I'm assuming GNU find here)



    Using just



    find filename


    would be quick, because it would just return filename, or the names inside filename if it's a directory, or an error if that name did not exist in the current directory. It's a very quick operation, similar to ls filename (but recursive if filename is a directory).



    In contrast,



    find | grep filename


    would allow find to generate a list of all names from the current directory and below, which grep would then filter. This would obviously be a much slower operation.



    I'm assuming that what was actually intended was



    find . -type f -name 'filename'


    This would look for filename as the name of a regular file anywhere in the current directory or below.



    This will be as quick (or comparably quick) as find | grep filename, but the grep solution would match filename against the full path of each found name, similarly to what -path '*filename*' would do with find.




    The confusion comes from a misunderstanding of how find works.



    The utility takes a number of paths and returns all names beneath these paths.



    You may then restrict the returned names using various tests that may act on the filename, the path, the timestamp, the file size, the file type, etc.



    When you say



    find a b c


    you ask find to list every name available under the three paths a, b and c. If these happens to be names of regular files in the current directory, then these will be returned. If any of them happens to be the name of a directory, then it will be returned along with all further names inside that directory.



    When I do



    find . -type f -name 'filename'


    This generates a list of all names in the current directory (.) and below. Then it restricts the names to those of regular files, i.e. not directories etc., with -type f. Then there is a further restriction to names that matches filename using -name 'filename'. The string filename may be a filename globbing pattern, such as *.txt (just remember to quote it!).



    Example:



    The following seems to "find" the file called .profile in my home directory:



    $ pwd
    /home/kk
    $ find .profile
    .profile


    But in fact, it just returns all names at the path .profile (there is only one name, and that is of this file).



    Then I cd up one level and try again:



    $ cd ..
    $ pwd
    /home
    $ find .profile
    find: .profile: No such file or directory


    The find command can now not find any path called .profile.



    However, if I get it to look at the current directory, and then restrict the returned names to only .profile, it finds it from there as well:



    $ pwd
    /home
    $ find . -name '.profile'
    ./kk/.profile





    share|improve this answer














    (I'm assuming GNU find here)



    Using just



    find filename


    would be quick, because it would just return filename, or the names inside filename if it's a directory, or an error if that name did not exist in the current directory. It's a very quick operation, similar to ls filename (but recursive if filename is a directory).



    In contrast,



    find | grep filename


    would allow find to generate a list of all names from the current directory and below, which grep would then filter. This would obviously be a much slower operation.



    I'm assuming that what was actually intended was



    find . -type f -name 'filename'


    This would look for filename as the name of a regular file anywhere in the current directory or below.



    This will be as quick (or comparably quick) as find | grep filename, but the grep solution would match filename against the full path of each found name, similarly to what -path '*filename*' would do with find.




    The confusion comes from a misunderstanding of how find works.



    The utility takes a number of paths and returns all names beneath these paths.



    You may then restrict the returned names using various tests that may act on the filename, the path, the timestamp, the file size, the file type, etc.



    When you say



    find a b c


    you ask find to list every name available under the three paths a, b and c. If these happens to be names of regular files in the current directory, then these will be returned. If any of them happens to be the name of a directory, then it will be returned along with all further names inside that directory.



    When I do



    find . -type f -name 'filename'


    This generates a list of all names in the current directory (.) and below. Then it restricts the names to those of regular files, i.e. not directories etc., with -type f. Then there is a further restriction to names that matches filename using -name 'filename'. The string filename may be a filename globbing pattern, such as *.txt (just remember to quote it!).



    Example:



    The following seems to "find" the file called .profile in my home directory:



    $ pwd
    /home/kk
    $ find .profile
    .profile


    But in fact, it just returns all names at the path .profile (there is only one name, and that is of this file).



    Then I cd up one level and try again:



    $ cd ..
    $ pwd
    /home
    $ find .profile
    find: .profile: No such file or directory


    The find command can now not find any path called .profile.



    However, if I get it to look at the current directory, and then restrict the returned names to only .profile, it finds it from there as well:



    $ pwd
    /home
    $ find . -name '.profile'
    ./kk/.profile






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Oct 3 '17 at 13:59

























    answered Oct 3 '17 at 10:56









    Kusalananda

    105k14209326




    105k14209326







    • 1




      find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
      – Stéphane Chazelas
      Oct 3 '17 at 11:52












    • 1




      find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
      – Stéphane Chazelas
      Oct 3 '17 at 11:52







    1




    1




    find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
    – Stéphane Chazelas
    Oct 3 '17 at 11:52




    find filename would return only filename if filename was not of type directory (or was of type directory, but did not have any entry itself)
    – Stéphane Chazelas
    Oct 3 '17 at 11:52












    up vote
    0
    down vote













    Notice: I'll assume that you mean find . -name filename (otherwise, you're looking for different things; find filename actually looks into a path called filename, which might contain almost no files, hence exiting really quickly).




    Suppose you have a directory holding five thousand files. On most filesystems, these files are actually stored in a tree structure, which allows to quickly locate any one given file.



    So when you ask find to locate a file whose name only requires checking, find will ask for that file, and that file only, to the underlying filesystem, which will read very few pages from the mass storage. So if the filesystem is worth its salt, this operation will run much faster than traversing the whole tree to retrieve all entries.



    When you ask for plain find however that's exactly what you do, you traverse the whole tree, reading. Every. Single. Entry. With large directories, this might be a problem (it's exactly the reason why several softwares, needing to store lots of files on disk, will create "directory trees" two or three components deep: this way, every single leaf only needs to hold fewer files).






    share|improve this answer


























      up vote
      0
      down vote













      Notice: I'll assume that you mean find . -name filename (otherwise, you're looking for different things; find filename actually looks into a path called filename, which might contain almost no files, hence exiting really quickly).




      Suppose you have a directory holding five thousand files. On most filesystems, these files are actually stored in a tree structure, which allows to quickly locate any one given file.



      So when you ask find to locate a file whose name only requires checking, find will ask for that file, and that file only, to the underlying filesystem, which will read very few pages from the mass storage. So if the filesystem is worth its salt, this operation will run much faster than traversing the whole tree to retrieve all entries.



      When you ask for plain find however that's exactly what you do, you traverse the whole tree, reading. Every. Single. Entry. With large directories, this might be a problem (it's exactly the reason why several softwares, needing to store lots of files on disk, will create "directory trees" two or three components deep: this way, every single leaf only needs to hold fewer files).






      share|improve this answer
























        up vote
        0
        down vote










        up vote
        0
        down vote









        Notice: I'll assume that you mean find . -name filename (otherwise, you're looking for different things; find filename actually looks into a path called filename, which might contain almost no files, hence exiting really quickly).




        Suppose you have a directory holding five thousand files. On most filesystems, these files are actually stored in a tree structure, which allows to quickly locate any one given file.



        So when you ask find to locate a file whose name only requires checking, find will ask for that file, and that file only, to the underlying filesystem, which will read very few pages from the mass storage. So if the filesystem is worth its salt, this operation will run much faster than traversing the whole tree to retrieve all entries.



        When you ask for plain find however that's exactly what you do, you traverse the whole tree, reading. Every. Single. Entry. With large directories, this might be a problem (it's exactly the reason why several softwares, needing to store lots of files on disk, will create "directory trees" two or three components deep: this way, every single leaf only needs to hold fewer files).






        share|improve this answer














        Notice: I'll assume that you mean find . -name filename (otherwise, you're looking for different things; find filename actually looks into a path called filename, which might contain almost no files, hence exiting really quickly).




        Suppose you have a directory holding five thousand files. On most filesystems, these files are actually stored in a tree structure, which allows to quickly locate any one given file.



        So when you ask find to locate a file whose name only requires checking, find will ask for that file, and that file only, to the underlying filesystem, which will read very few pages from the mass storage. So if the filesystem is worth its salt, this operation will run much faster than traversing the whole tree to retrieve all entries.



        When you ask for plain find however that's exactly what you do, you traverse the whole tree, reading. Every. Single. Entry. With large directories, this might be a problem (it's exactly the reason why several softwares, needing to store lots of files on disk, will create "directory trees" two or three components deep: this way, every single leaf only needs to hold fewer files).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 3 '17 at 17:29

























        answered Oct 3 '17 at 13:26









        LSerni

        2,326615




        2,326615




















            up vote
            0
            down vote













            I have not understood the problem yet but can provide some more insights.



            Like for Kusalananda the find | grep call is clearly faster on my system which does not make much sense. At first I assumed some kind of buffering problem; that writing to the console slows down the time to the next syscall for reading the next file name. Writing to a pipe is very fast: about 40MiB/s even for 32-byte writes (on my rather slow system; 300 MiB/s for a block size of 1MiB). Thus I assumed that find can read from the file system faster when writing to a pipe (or file) so that the two operations reading file paths and writing to the console could run in parallel (which find as a single thread process cannot do on its own.



            It's find's fault



            Comparing the two calls



            :> time find "$HOME"/ -name '*.txt' >/dev/null

            real 0m0.965s
            user 0m0.532s
            sys 0m0.423s


            and



            :> time find "$HOME"/ >/dev/null

            real 0m0.653s
            user 0m0.242s
            sys 0m0.405s


            shows that find does something incredibly stupid (whatever that may be). It just turns out to be quite incompetent at executing -name '*.txt'.



            Might depend on the input / output ratio



            You might think that find -name wins if there is very little to write. But ist just gets more embarrassing for find. It loses even if there is nothing to write at all against 200K files (13M of pipe data) for grep:



            time find /usr -name lwevhewoivhol


            find can be as fast as grep, though



            It turns out that find's stupidity with name does not extend to other tests. Use a regex instead and the problem is gone:



            :> time find "$HOME"/ -regex '.txt$' >/dev/null 

            real 0m0.679s
            user 0m0.264s
            sys 0m0.410s


            I guess this can be considered a bug. Anyone willing to file a bug report? My version is find (GNU findutils) 4.6.0






            share|improve this answer






















            • How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
              – psmears
              Oct 3 '17 at 16:09










            • @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
              – Hauke Laging
              Oct 3 '17 at 18:24










            • Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
              – Barmar
              Oct 4 '17 at 18:01










            • @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
              – Hauke Laging
              Oct 5 '17 at 8:10










            • Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
              – Barmar
              Oct 5 '17 at 15:39














            up vote
            0
            down vote













            I have not understood the problem yet but can provide some more insights.



            Like for Kusalananda the find | grep call is clearly faster on my system which does not make much sense. At first I assumed some kind of buffering problem; that writing to the console slows down the time to the next syscall for reading the next file name. Writing to a pipe is very fast: about 40MiB/s even for 32-byte writes (on my rather slow system; 300 MiB/s for a block size of 1MiB). Thus I assumed that find can read from the file system faster when writing to a pipe (or file) so that the two operations reading file paths and writing to the console could run in parallel (which find as a single thread process cannot do on its own.



            It's find's fault



            Comparing the two calls



            :> time find "$HOME"/ -name '*.txt' >/dev/null

            real 0m0.965s
            user 0m0.532s
            sys 0m0.423s


            and



            :> time find "$HOME"/ >/dev/null

            real 0m0.653s
            user 0m0.242s
            sys 0m0.405s


            shows that find does something incredibly stupid (whatever that may be). It just turns out to be quite incompetent at executing -name '*.txt'.



            Might depend on the input / output ratio



            You might think that find -name wins if there is very little to write. But ist just gets more embarrassing for find. It loses even if there is nothing to write at all against 200K files (13M of pipe data) for grep:



            time find /usr -name lwevhewoivhol


            find can be as fast as grep, though



            It turns out that find's stupidity with name does not extend to other tests. Use a regex instead and the problem is gone:



            :> time find "$HOME"/ -regex '.txt$' >/dev/null 

            real 0m0.679s
            user 0m0.264s
            sys 0m0.410s


            I guess this can be considered a bug. Anyone willing to file a bug report? My version is find (GNU findutils) 4.6.0






            share|improve this answer






















            • How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
              – psmears
              Oct 3 '17 at 16:09










            • @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
              – Hauke Laging
              Oct 3 '17 at 18:24










            • Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
              – Barmar
              Oct 4 '17 at 18:01










            • @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
              – Hauke Laging
              Oct 5 '17 at 8:10










            • Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
              – Barmar
              Oct 5 '17 at 15:39












            up vote
            0
            down vote










            up vote
            0
            down vote









            I have not understood the problem yet but can provide some more insights.



            Like for Kusalananda the find | grep call is clearly faster on my system which does not make much sense. At first I assumed some kind of buffering problem; that writing to the console slows down the time to the next syscall for reading the next file name. Writing to a pipe is very fast: about 40MiB/s even for 32-byte writes (on my rather slow system; 300 MiB/s for a block size of 1MiB). Thus I assumed that find can read from the file system faster when writing to a pipe (or file) so that the two operations reading file paths and writing to the console could run in parallel (which find as a single thread process cannot do on its own.



            It's find's fault



            Comparing the two calls



            :> time find "$HOME"/ -name '*.txt' >/dev/null

            real 0m0.965s
            user 0m0.532s
            sys 0m0.423s


            and



            :> time find "$HOME"/ >/dev/null

            real 0m0.653s
            user 0m0.242s
            sys 0m0.405s


            shows that find does something incredibly stupid (whatever that may be). It just turns out to be quite incompetent at executing -name '*.txt'.



            Might depend on the input / output ratio



            You might think that find -name wins if there is very little to write. But ist just gets more embarrassing for find. It loses even if there is nothing to write at all against 200K files (13M of pipe data) for grep:



            time find /usr -name lwevhewoivhol


            find can be as fast as grep, though



            It turns out that find's stupidity with name does not extend to other tests. Use a regex instead and the problem is gone:



            :> time find "$HOME"/ -regex '.txt$' >/dev/null 

            real 0m0.679s
            user 0m0.264s
            sys 0m0.410s


            I guess this can be considered a bug. Anyone willing to file a bug report? My version is find (GNU findutils) 4.6.0






            share|improve this answer














            I have not understood the problem yet but can provide some more insights.



            Like for Kusalananda the find | grep call is clearly faster on my system which does not make much sense. At first I assumed some kind of buffering problem; that writing to the console slows down the time to the next syscall for reading the next file name. Writing to a pipe is very fast: about 40MiB/s even for 32-byte writes (on my rather slow system; 300 MiB/s for a block size of 1MiB). Thus I assumed that find can read from the file system faster when writing to a pipe (or file) so that the two operations reading file paths and writing to the console could run in parallel (which find as a single thread process cannot do on its own.



            It's find's fault



            Comparing the two calls



            :> time find "$HOME"/ -name '*.txt' >/dev/null

            real 0m0.965s
            user 0m0.532s
            sys 0m0.423s


            and



            :> time find "$HOME"/ >/dev/null

            real 0m0.653s
            user 0m0.242s
            sys 0m0.405s


            shows that find does something incredibly stupid (whatever that may be). It just turns out to be quite incompetent at executing -name '*.txt'.



            Might depend on the input / output ratio



            You might think that find -name wins if there is very little to write. But ist just gets more embarrassing for find. It loses even if there is nothing to write at all against 200K files (13M of pipe data) for grep:



            time find /usr -name lwevhewoivhol


            find can be as fast as grep, though



            It turns out that find's stupidity with name does not extend to other tests. Use a regex instead and the problem is gone:



            :> time find "$HOME"/ -regex '.txt$' >/dev/null 

            real 0m0.679s
            user 0m0.264s
            sys 0m0.410s


            I guess this can be considered a bug. Anyone willing to file a bug report? My version is find (GNU findutils) 4.6.0







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Oct 3 '17 at 18:22

























            answered Oct 3 '17 at 13:01









            Hauke Laging

            53.7k1282130




            53.7k1282130











            • How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
              – psmears
              Oct 3 '17 at 16:09










            • @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
              – Hauke Laging
              Oct 3 '17 at 18:24










            • Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
              – Barmar
              Oct 4 '17 at 18:01










            • @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
              – Hauke Laging
              Oct 5 '17 at 8:10










            • Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
              – Barmar
              Oct 5 '17 at 15:39
















            • How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
              – psmears
              Oct 3 '17 at 16:09










            • @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
              – Hauke Laging
              Oct 3 '17 at 18:24










            • Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
              – Barmar
              Oct 4 '17 at 18:01










            • @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
              – Hauke Laging
              Oct 5 '17 at 8:10










            • Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
              – Barmar
              Oct 5 '17 at 15:39















            How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
            – psmears
            Oct 3 '17 at 16:09




            How repeatable are your timings? If you did the -name test first, then it may have been slower due to the directory contents not being cached. (When testing -name and -regex I find they take roughly the same time, at least once the cache effect has been taken into consideration. Of course it may just be a different version of find...)
            – psmears
            Oct 3 '17 at 16:09












            @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
            – Hauke Laging
            Oct 3 '17 at 18:24




            @psmears Of course, I have done these tests several times. The caching problem has been mentioned even in the comments to the question before the first answer. My find version is find (GNU findutils) 4.6.0
            – Hauke Laging
            Oct 3 '17 at 18:24












            Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
            – Barmar
            Oct 4 '17 at 18:01




            Why is it surprising that adding -name '*.txt' slows down find? It has to do extra work, testing each filename.
            – Barmar
            Oct 4 '17 at 18:01












            @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
            – Hauke Laging
            Oct 5 '17 at 8:10




            @Barmar One the one hand this extra work can be done extremely fast. On the other hand this extra work saves other work. find has to write less data. And writing to a pipe is a much slower operation.
            – Hauke Laging
            Oct 5 '17 at 8:10












            Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
            – Barmar
            Oct 5 '17 at 15:39




            Writing to a disk is very slow, writing to a pipe is not so bad, it just copies to a kernel buffer. Notice that in your first test, writing more to /dev/null somehow used less system time.
            – Barmar
            Oct 5 '17 at 15:39










            up vote
            0
            down vote













            Non-Technical explanation: Looking for Jack in a crowd is faster than looking for everyone in a crowd and eliminating all from consideration except Jack.






            share|improve this answer




















            • The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
              – Kusalananda
              Oct 4 '17 at 13:56















            up vote
            0
            down vote













            Non-Technical explanation: Looking for Jack in a crowd is faster than looking for everyone in a crowd and eliminating all from consideration except Jack.






            share|improve this answer




















            • The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
              – Kusalananda
              Oct 4 '17 at 13:56













            up vote
            0
            down vote










            up vote
            0
            down vote









            Non-Technical explanation: Looking for Jack in a crowd is faster than looking for everyone in a crowd and eliminating all from consideration except Jack.






            share|improve this answer












            Non-Technical explanation: Looking for Jack in a crowd is faster than looking for everyone in a crowd and eliminating all from consideration except Jack.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 4 '17 at 13:15









            S Renalds

            1




            1











            • The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
              – Kusalananda
              Oct 4 '17 at 13:56

















            • The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
              – Kusalananda
              Oct 4 '17 at 13:56
















            The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
            – Kusalananda
            Oct 4 '17 at 13:56





            The problem is that the OP is expecting Jack to be the only person in the crowd. If it is, they're lucky. find jack will list jack if it's a file called jack, or all names in the directory if it's a directory. It's a misunderstanding of how find works.
            – Kusalananda
            Oct 4 '17 at 13:56











            up vote
            -2
            down vote













            Lets assume the file /john/paul/george/ringo/beatles exists and the file you are searching for is called 'stones'



            find / stones


            find will compare 'beatles' to 'stones' and drop it when the 's' and 'b' don't match.



            find / | grep stones


            In this case find will pass '/john/paul/george/ringo/beatles' to grep and grep will have to work its way through the entire path before determining if its a match.



            grep is therefore doing far more work which is why it takes longer






            share|improve this answer
















            • 1




              Have you given that a try?
              – Hauke Laging
              Oct 3 '17 at 12:37






            • 3




              The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
              – Mat
              Oct 3 '17 at 12:44











            • grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
              – Paranoid
              Oct 3 '17 at 13:00










            • @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
              – pipe
              Oct 3 '17 at 19:11














            up vote
            -2
            down vote













            Lets assume the file /john/paul/george/ringo/beatles exists and the file you are searching for is called 'stones'



            find / stones


            find will compare 'beatles' to 'stones' and drop it when the 's' and 'b' don't match.



            find / | grep stones


            In this case find will pass '/john/paul/george/ringo/beatles' to grep and grep will have to work its way through the entire path before determining if its a match.



            grep is therefore doing far more work which is why it takes longer






            share|improve this answer
















            • 1




              Have you given that a try?
              – Hauke Laging
              Oct 3 '17 at 12:37






            • 3




              The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
              – Mat
              Oct 3 '17 at 12:44











            • grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
              – Paranoid
              Oct 3 '17 at 13:00










            • @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
              – pipe
              Oct 3 '17 at 19:11












            up vote
            -2
            down vote










            up vote
            -2
            down vote









            Lets assume the file /john/paul/george/ringo/beatles exists and the file you are searching for is called 'stones'



            find / stones


            find will compare 'beatles' to 'stones' and drop it when the 's' and 'b' don't match.



            find / | grep stones


            In this case find will pass '/john/paul/george/ringo/beatles' to grep and grep will have to work its way through the entire path before determining if its a match.



            grep is therefore doing far more work which is why it takes longer






            share|improve this answer












            Lets assume the file /john/paul/george/ringo/beatles exists and the file you are searching for is called 'stones'



            find / stones


            find will compare 'beatles' to 'stones' and drop it when the 's' and 'b' don't match.



            find / | grep stones


            In this case find will pass '/john/paul/george/ringo/beatles' to grep and grep will have to work its way through the entire path before determining if its a match.



            grep is therefore doing far more work which is why it takes longer







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 3 '17 at 11:53









            Paranoid

            622




            622







            • 1




              Have you given that a try?
              – Hauke Laging
              Oct 3 '17 at 12:37






            • 3




              The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
              – Mat
              Oct 3 '17 at 12:44











            • grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
              – Paranoid
              Oct 3 '17 at 13:00










            • @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
              – pipe
              Oct 3 '17 at 19:11












            • 1




              Have you given that a try?
              – Hauke Laging
              Oct 3 '17 at 12:37






            • 3




              The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
              – Mat
              Oct 3 '17 at 12:44











            • grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
              – Paranoid
              Oct 3 '17 at 13:00










            • @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
              – pipe
              Oct 3 '17 at 19:11







            1




            1




            Have you given that a try?
            – Hauke Laging
            Oct 3 '17 at 12:37




            Have you given that a try?
            – Hauke Laging
            Oct 3 '17 at 12:37




            3




            3




            The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
            – Mat
            Oct 3 '17 at 12:44





            The cost of the string comparisons (extremely simple and cheap) is completely dwarfed by the IO (or just syscall if cached) cost of the directory lookups .
            – Mat
            Oct 3 '17 at 12:44













            grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
            – Paranoid
            Oct 3 '17 at 13:00




            grep isn't a string comparison, its regular expression comparison which means it has to work its way through the entire string until it either finds a match or reaches the end. The directory lookups are the same no matter what.
            – Paranoid
            Oct 3 '17 at 13:00












            @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
            – pipe
            Oct 3 '17 at 19:11




            @Paranoid Hm, what version of find are you talking about? It's apparently not anything like the find I'm used to in debian.
            – pipe
            Oct 3 '17 at 19:11

















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f395801%2fwhy-is-the-command-find-grep-filename-so-much-slower-than-find-filename%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?