> On 24 Apr 2022, at 12:23, Olaf Meeuwissen via Dng <dng@???> wrote:
>
> Hi,
>
> Antony Stone <Antony.Stone@???> 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
::
Re: [DNG] mouse driver question
