Como cronometrar comandos grep com precisão?

Eu quero comparar a velocidade desses dois comandos:

grep pattern1 files* 
grep pattern2 files*

Infelizmente, o primeiro grep lê muitos arquivos * em buffers de memória, portanto o segundo grep é executado muito rapidamente, mas pelo motivo errado.

Como eu digo ao Linux (Fedora 11): "por favor, pare de armazenar em cache as leituras de disco porque estou testando alguma coisa."

hard-disk cache measure

— barrycarter
fonte

Provavelmente há uma resposta mais inteligente ... mas você pode duplicar a estrutura de diretórios, para não lidar com o mesmo arquivo e não terá problemas de cache!

— Nico

Como um aparte: o Fedora 11 chegou ao fim da vida útil em junho de 2010. É hora de atualizar. O próximo lançamento do Fedora 15 parece muito bom. Ou, se você precisa de algo mais estável ao longo de um tempo de vida mais longo (e parece que você pode desde que você ainda está em 11), há RHEL6 ou-qualquer-dia agora CentOS 6.

— mattdm

Levei uma eternidade para atualizar do RH 7.3 para isso! As atualizações quebram as coisas e me assustam.

— #

Ao desativar o cache, você avaliará não a velocidade da correspondência de padrões, mas a velocidade da sua unidade. Como outros sugerem - basta executar o primeiro comando duas vezes: primeiro para preparar o cache, depois para o benchmark.

— alex

Vou tentar, mas meu principal problema é a velocidade do disco ... o disco rígido fica louco quando executo o grep. Hmmm, ok, então isso pode significar que otimizar o grep pode não ajudar em nada ... Preciso otimizar a quantidade de dados que estou puxando.

— #

Respostas:

Eu não acho que você possa facilmente dizer "pare temporariamente o cache". Mas o que você pode fazer é dizer ao sistema para eliminar o cache antes de cada execução:

Como raiz:

sync; echo 3 > /proc/sys/vm/drop_caches

(Isso está documentado nos documentos do kernel em Documentation / sysctl / vm.txt , o que é útil se, como alguns de nós, você nem sempre consegue se lembrar de imediato do que os valores 1, 2 ou 3 fazem.)

Ou, como alternativa, é claro, prepare o cache e compare o desempenho em cache. (Eu acho que ambos são números úteis.)

— mattdm
fonte

echo 1somente eliminará o cache da página, não os caches de disco.

— Jsbillings # 01/03

@jsbillings - er, sim. Fixo.

— mattdm

Incrivelmente menor picuinhas: eu tinha que fazer ">>", não ">"

— barrycarter

@ barrycarter: realmente? Hã!

— mattdm

@ barrycarter: você provavelmente configurou -o noclobber em seu shell, o que faz com que ele não permita que você use> para substituir um arquivo existente.

— Jsbillings # 01/03

Ao cronometrar coisas como essa, geralmente eu a executo primeiro para preparar o cache. Em seguida, execute o comando usando o tempo. Ao testar algo assim, você deve se preocupar mais com a CPU e os tempos decorridos e menos com o tempo de E / S.

De qualquer forma, é difícil obter horários totalmente precisos. Se os arquivos de entrada excederem o tamanho da memória disponível para buffers, você provavelmente terminará o ciclo de todos os arquivos através do cache do buffer. Caso contrário, você poderá acessar todos os dados do cache do buffer. Na vida real, geralmente há uma mistura de dados em buffer e dados lidos no disco.

— BillThor
fonte

IRL, eu executo esse comando apenas ocasionalmente, para que o conteúdo dos arquivos * nunca seja armazenado em cache. Estou tentando otimizar o grep para executar rapidamente nessa situação. Quando os arquivos * conteúdos já estão no cache, ele é executado em menos de um segundo (nenhum ponto na otimização que, desde a produção se destina ao usuário final)

— barrycarter

@barrycarter. Se os arquivos não estiverem armazenados em cache e forem executados em menos de um segundo quando estiverem, acho que você não encontrará muitas oportunidades de otimização. Mover os arquivos para um armazenamento mais rápido seria a provável otimização.

— BillThor