> On 24 Apr 2022, at 12:23, Olaf Meeuwissen via Dng <dng@lists.dyne.org> wrote: > > Hi, > > Antony Stone <antony.st...@devuan.open.source.it> writes: > >>> On Saturday 23 April 2022 at 22:57:12, Florian Zieboll via Dng wrote: >>> >>> On Sat, 23 Apr 2022 21:15:34 +0200 Antony Stone wrote: >>>> On Saturday 23 April 2022 at 21:11:18, Florian Zieboll via Dng wrote: >>>> >>>>> Some time ago, in a similar situation, I had been successful with >>>>> >>>>> $ find / | grep xorg.conf >>>> >>>> Personally I'd have gone for: >>>> find / -name xorg.conf >>> >>> I may be wrong (and nitpicking;) - but I think that your approach is >>> less fast, as 'find' does the file name matching /before/ it continues >>> searching - in opposite to just piping its output to grep and going on >>> with running down the file system hierarchy without any interruption. >> >> Interesting - and you're right. >> >> I just tried several successive searches for a few unique filenames in a >> directory tree (all files in the same directory, just in case the position >> made >> a difference). >> >> The first search took 6 minutes and clearly set up some cache of results, >> because subsequent searches were consistently: >> >> find . | grep filename : 20 seconds >> >> find . -name filename : 25 seconds >> >> That was consistent no matter whether the two filenames were the same, or >> different but still in the same directory, and no matter which command was >> run >> first. >> >> Nice observation. > > Indeed but you must have an awful lot of files, slow disks and/or a slow > network connection. After setting up the cache on my machine, I get 0.7 > seconds for the -name approach and 0.5 seconds for grep. > That's with close to half a million filesystem entries and about 7000 of > those on an NFS backed filesystem on the NAS downstairs. The rest is on > an SSD (NVMe). > > Another point, the grep approach also lists everything below a directory > that matches, whereas the -name approach does not. That may be a lot of > extra junk to scan through depending on what you're looking for. > That's also why I suggested redirecting errors to /dev/null when looking > for stuff below / as a normal user ;-) > > Hope this helps, > -- > Olaf Meeuwissen
How does this speed compare to mlocate or whatever is the preferred version of locate database these days? -- Tom _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
