Existe uma maneira de comparar o comando find (para comparar com o locate)?

Question

Lendo a resposta aceita da pergunta localizar vs find: uso, prós e contras uns dos outros que diz que a principal vantagem do locate é a rapidez Eu queria fazer alguns testes, se eu posso me beneficiar do seu uso.

Meu primeiro passo foi estimar a velocidade da ferramenta find ao fornecer um serviço comparável como locate (portanto, apenas pesquisando nomes de arquivos, sem extras).

Fiquei surpreso ao ver que

time find / 2>/dev/null >/dev/null

que eu supus iterar sobre todos os arquivos (dependendo das permissões dos usuários), mostrei

real    0m1.231s
user    0m0.353s
sys 0m0.867s

um resultado bastante rápido.

Minha pergunta é se o comando aplicado é uma forma de realmente avaliar a velocidade de find ?

Um aspecto da pergunta que eu estaria interessado em responder seria se houvesse algum tipo de buffers no sistema de arquivos, portanto no SO (que é um kernel do Linux), o que impactaria o resultado?

Meus resultados, nos quais o droping dos caches via echo 3 > /proc/sys/vm/drop_caches aumentou muito a velocidade de find :

$ 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

No entanto, no meu sistema Linux, o uso subsequente de find retornou a velocidades semelhantes a mlocate de cerca de 1sec?

Resumindo, estou interessado em conhecer uma maneira de comparar o comando find (para comparar com o locate)

Atualizar / comentar

Enquanto a pergunta foi motivada por outra que compara locate com find e eu pergunto sobre a medição / benchmarking da velocidade de find estou ciente de que é altamente improvável que coleta de dados do SO / sistema de arquivos ao vivo ou seja, find ), seria mais rápido do que uma pesquisa em uma consulta ao banco de dados (ou seja, locate ). Com o bom comportamento de armazenamento em cache do meu kernel de sistemas operacionais, eu ainda tive tempos de execução bastante semelhantes para pesquisar via find ou locate .

A questão, portanto, resume-se a se é suficiente descartar os caches dos sistemas de operação (sistema de arquivos), para simular o tempo "real" necessário para um find feito em uma partida a frio e, além disso, quão realista seria assumir que esses caches de aprimoramento de velocidade persistem (não semelhantes ao arquivo de banco de dados updatedb locate ) para todas as chamadas find subseqüentes.

    

Answer 1

No OpenBSD , o banco de dados de localização é, por padrão, reconstruído uma vez por semana pelo /etc/weekly script chamando /usr/libexec/locate.updatedb como usuário nobody .

O utilitário locate.updatedb é um script /bin/sh ( pdksh no OpenBSD) que mais ou menos executa find nos sistemas de arquivos raiz. Qualquer coisa que nobody possa acessar é colocada no banco de dados de localização.

Acho difícil acreditar que find / seria mais rápido que locate em um sistema no qual locate usa um banco de dados de arquivos criado por meio de find / .

A diferença é, obviamente, que você pode encontrar mais arquivos executando find como um usuário que tenha mais acesso do que o usuário nobody .

No Linux , pelo menos na máquina Ubuntu a que tenho acesso no trabalho, o banco de dados locate parece ser recriado diariamente, de acordo com o manual locate(8) . Isso é feito através do utilitário updatedb .

Este utilitário (um link simbólico para /usr/bin/updatedb.mlocate nesta máquina) é um binário compilado pertencente ao pacote mlocate .

Você pode dar uma olhada em as fontes de mlocate se quiser, mas é basicamente um programa em C que atravessa o sistema de arquivos. mlocate também tenta evitar a passagem de bits do sistema de arquivos que não mudou entre as execuções.

Mais uma vez, acho difícil acreditar que consultar o banco de dados mlocate seria mais lento (sob quaisquer circunstâncias) do que executar find / .

No final do dia, é por isso que todas as ferramentas locate (que eu conheço) funcionam em um banco de dados.