Come si cronometrano i comandi grep con precisione?

Voglio confrontare la velocità di questi due comandi:

grep pattern1 files* 
grep pattern2 files*

Sfortunatamente, il primo grep legge gran parte dei file * nei buffer di memoria, quindi il secondo grep viene eseguito molto rapidamente, ma per la ragione sbagliata.

Come dico a Linux (Fedora 11): "per favore, smetti di leggere le letture del disco perché sto testando qualcosa".

hard-disk cache measure

— barrycarter
fonte

Probabilmente c'è una risposta più intelligente ... ma potresti duplicare la struttura della directory, quindi non avrai a che fare con lo stesso file e non avrai problemi di memorizzazione nella cache!

— nico

A parte questo: Fedora 11 ha raggiunto la fine del ciclo di vita nel giugno 2010. È tempo di aggiornare. La prossima uscita di Fedora 15 sembra davvero bella. Oppure, se hai bisogno di qualcosa di più stabile per una durata di vita più lunga (e suona come potresti, dato che sei ancora su 11), c'è RHEL6 o CentOS 6. da un giorno

— all'altro

Mi ci è voluto per sempre per passare da RH 7.3 a quello! Gli aggiornamenti rompono le cose e mi spaventano.

— Barrycarter

Disattivando la memorizzazione nella cache, eseguirai un benchmark non della velocità di corrispondenza dei modelli, ma della velocità dell'unità. Come altri suggeriscono, basta eseguire il primo comando due volte: primo per adescare la cache, secondo per benchmark.

— alex

Ci proverò, ma il mio problema principale è la velocità del disco ... il disco rigido impazzisce quando eseguo il grep. Hmmm, ok, quindi ciò potrebbe significare che l'ottimizzazione del grep potrebbe non aiutare affatto ... Devo ottimizzare la quantità di dati che sto estraendo.

— Barrycarter

Risposte:

Non credo che tu possa facilmente dirlo "smetti temporaneamente di memorizzare nella cache". Ma quello che puoi fare è dire al sistema di eliminare la cache prima di ogni esecuzione:

Come root:

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

(Questo è documentato nei documenti del kernel in Documentation / sysctl / vm.txt , il che è utile se come alcuni di noi non riesci sempre a ricordare a mano cosa fanno i valori 1, 2 o 3.)

In alternativa, ovviamente, adescare la cache e confrontare le prestazioni memorizzate nella cache. (Penso che entrambi siano numeri utili.)

— mattdm
fonte

echo 1eliminerà solo la cache della pagina, non tutte le cache del disco.

— jsbillings

@jsbillings - ehm, sì. Fisso.

— Mattdm,

Un nitpicking incredibilmente minore: ho dovuto fare ">>", non ">"

— barrycarter

@barrycarter: davvero? eh!

— Mattdm,

@barrycarter: probabilmente hai impostato -o noclobber nella tua shell, il che lo rende così non ti permetterà di usare> per sovrascrivere un file esistente.

— jsbillings

Quando cronometri cose come queste, di solito lo eseguo prima per adescare la cache. Quindi eseguire il comando usando time. Nel testare qualcosa del genere dovresti essere più preoccupato per la CPU e i tempi trascorsi, e meno preoccupato per il tempo di I / O.

In ogni caso è difficile ottenere tempistiche completamente accurate. Se i file di input superano la dimensione della memoria disponibile per i buffer, probabilmente finirai per scorrere tutti i file nella cache del buffer. Altrimenti, è possibile accedere a tutti i dati dalla cache del buffer. Nella vita reale, c'è spesso un mix di dati bufferizzati e dati letti dal disco.

— BillThor
fonte

IRL, eseguo questo comando solo occasionalmente, quindi i file * non vengono mai memorizzati nella cache. Sto cercando di ottimizzare il grep per correre veloce in quella situazione. Quando il contenuto dei file * è già nella cache, viene eseguito in meno di un secondo (non ha senso ottimizzarlo, poiché l'output è destinato all'utente finale)

— barrycarter

@barrycarter. Se i file non sono memorizzati nella cache e vengono eseguiti in meno di un secondo quando lo sono, non penso che troverai molte opportunità di ottimizzazione. Spostare i file in un archivio più veloce sarebbe la probabile ottimizzazione.

— BillThor