Reading the accetped answer of the question locate vs find: usage, pros and cons of each other which tells that
locate's main advantage is speed I wanted to do some testing, whether I can benefit from its usage.
My first step was to estimate the speed of
find tool when providing a comparable service as
locate (hence only searching filenames, no extras).
I was surprised to see that
time find / 2>/dev/null >/dev/null
which I assumed iterates over all files (depended on the users permissions), showed
real 0m1.231s user 0m0.353s sys 0m0.867s
a rather quick result.
My question is if the applied command is a way to actually benchmark the speed of
An aspect of the question I would be interested to have answered would be if there are some sort of buffers in the filesystem, hence in the OS (which is a linux kernel), which would impact the result?
My results where that droping the caches via
echo 3 > /proc/sys/vm/drop_caches, vastly increased the speed of
$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches" $ time (find / 2>/dev/null >/dev/null) real 0m24.290s user 0m1.143s sys 0m8.230s
Yet on my linux system subsequent usage of
find returned to similar to
mlocate speeds of about 1sec?
Summed up, I am interested to know a way to benchmark the find command (to compare with locate)
While the question was motivated by another one comparing
find and I ask about measuring/benchmarking the speed of
find I am aware that is is highly unlikely that data gathering from the live OS/filesystem (i.e.
find) , would be faster then a lookup within a database lookup (i.e.
locate). With the rather good caching behaviour of my operation systems kernel I nonetheless had rather similar execution times for searching via
The question hence boils down to whether it is enough to drop the operation systems (filesystem) caches, to simulate the "actual" time needed for a
find done at a cold start and furthermore how realistic it would be to assume that those speed enhancing caches persists (not unsimilar to the
locate database file) for all subsequent