Le mie stringhe sono percorsi di file simili s/14/11/13/15/n7ce49B_235_25ed2d70.jpg; i miei schemi sono abbastanza semplici, tutti simili n7ce49B_.+.
Sto correndo GNU grep 2.6.3con Debian 6.0.10 sul server Dell DL360G7 (lo menziono solo per dare un senso di prestazioni di questa macchina) con HDD da 15k, e questo comando: time LC_ALL=C grep -E -f path_to_patterns_file path_to_strings_filesemplicemente impossibile completare - gli scambi di server sono troppo gravi. Con 20k pattern ci vogliono più di 3 ore.
Mi sembra irragionevole.
Per richiesta di commento, ci sono i file: percorsi di file 20k modelli
Si può anche testare e regolare il numero di linee e schemi di input con:
xxd -p /dev/urandom | fold -sw 100 | head -n 1250 |
grep -Ef <(xxd -p /dev/urandom | fold -sw 10 | head -n 20000)
Bene, 90k è la mia dimensione di input originale e questo rende la mia macchina di scambio così difficile che devo uccidere quel grep. Poi ho provato a dividere questo in 20k file e funziona ancora in modo orribile ... Ma hai ragione che la mia descrizione è incoerente.
—
skaurus,
Si prega di chiarire se il server potrebbe essere stato sovraccaricato o meno (eseguendo altre attività affamate di risorse) durante il
—
agc,
grep.
Si può riprodurre con
—
Stéphane Chazelas,
xxd -p /dev/urandom | fold -sw 100 | head -n 1250 | grep -Ef <(xxd -p /dev/urandom | fold -sw 10 | head -n 20000). Sembra che il tempo sia trascorso compilando le regexps e allocando molta memoria. Con -Finvece di -E, è istantaneo.
Per quello che importa, non
—
Stéphane Chazelas il
n7ce49B_.+è equivalente an7ce49B_.
90k, la descrizione ha20Kmotivi