¿Cómo cronometrar los comandos grep con precisión?

Quiero comparar la velocidad de estos dos comandos:

grep pattern1 files* 
grep pattern2 files*

Desafortunadamente, el primer grep lee gran parte de los archivos * en las memorias intermedias, por lo que el segundo grep se ejecuta muy rápidamente, pero por la razón equivocada.

¿Cómo le digo a Linux (Fedora 11): "por favor, deje de almacenar en caché las lecturas de disco porque estoy probando algo".

hard-disk cache measure

— barrycarter
fuente

Probablemente haya una respuesta más inteligente ... ¡pero podría duplicar la estructura del directorio, por lo que no tendrá que lidiar con el mismo archivo y no tendrá problemas de almacenamiento en caché!

— nico

Como un aparte: Fedora 11 llegó al final de su vida útil en junio de 2010. Es hora de actualizar. El próximo lanzamiento de Fedora 15 se ve muy bien. O, si necesita algo más estable durante una vida útil más larga (y parece que podría hacerlo porque todavía está en 11), hay RHEL6 o CentOS 6. en cualquier momento

— mattdm

¡Me llevó una eternidad actualizar de RH 7.3 a eso! Las actualizaciones rompen cosas y me asustan.

— barrycarter 01 de

Al desactivar el almacenamiento en caché, no comparará la velocidad de coincidencia de patrones, sino la velocidad de su unidad. Como sugieren otros, simplemente ejecute el primer comando dos veces: primero para cebar el caché, segundo para el punto de referencia.

— alex

Lo intentaré, pero mi problema principal es la velocidad del disco ... el disco duro se vuelve loco cuando ejecuto el grep. Hmmm, ok, eso puede significar que optimizar el grep puede no ayudar en absoluto ... Necesito optimizar la cantidad de datos que estoy extrayendo.

— barrycarter

Respuestas:

No creo que pueda decirle fácilmente "dejar temporalmente de almacenar en caché". Pero lo que puede hacer es decirle al sistema que deje caer el caché antes de cada ejecución:

Como root:

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

(Esto está documentado en los documentos del núcleo en Documentation / sysctl / vm.txt , lo cual es útil si, como algunos de nosotros, no siempre puede recordar de antemano lo que hacen los valores 1, 2 o 3).

O alternativamente, por supuesto, cebe el caché y compare el rendimiento en caché. (Creo que ambos son números útiles).

— mattdm
fuente

echo 1solo eliminará la memoria caché de la página, no ninguna memoria caché de disco.

— jsbillings

@jsbillings - er, sí. Fijo.

— mattdm

Mentiras increíblemente menores: tuve que hacer ">>", no ">"

— barrycarter

@barrycarter: ¿en serio? eh!

— mattdm

@barrycarter: probablemente haya configurado -o noclobber en su shell, lo que hace que no le permita usar> para sobrescribir un archivo existente.

— jsbillings

Al cronometrar cosas como esta, generalmente lo ejecuto primero para cebar el caché. Luego ejecute el comando usando el tiempo. Al probar algo como esto, debería estar más preocupado por la CPU y los tiempos transcurridos, y menos preocupado por el tiempo de E / S.

En cualquier caso, es difícil obtener tiempos totalmente precisos. Si los archivos de entrada exceden el tamaño de la memoria disponible para las memorias intermedias, es probable que termine ciclando todos los archivos a través de la memoria caché de la memoria intermedia. De lo contrario, puede acceder a todos los datos de la memoria caché del búfer. En la vida real, a menudo hay una combinación de datos almacenados y datos leídos del disco.

— BillThor
fuente

IRL, ejecuto este comando solo ocasionalmente, por lo que el contenido de los archivos * nunca se almacena en caché. Estoy tratando de optimizar el grep para correr rápido en esa situación. Cuando los archivos * contenidos ya están en la memoria caché, se ejecuta en menos de un segundo (ningún punto en la optimización de que, puesto que la salida está destinado a los usuarios finales)

— barrycarter

@barrycarter. Si los archivos no están en caché, y se ejecuta en menos de un segundo cuando lo están, entonces no creo que encuentre muchas oportunidades para la optimización. Mover los archivos a un almacenamiento más rápido sería la optimización más probable.

— BillThor