Perché il WC è così lento?

Perché l'utilità wc è così lenta?

Quando lo eseguo su un file di grandi dimensioni, ci vuole circa 20 volte più a lungo di md5sum:

MyDesktop:/tmp$ dd if=/dev/zero bs=1024k count=1024 of=/tmp/bigfile
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.687094 s, 1.6 GB/s

MyDesktop:/tmp$ time wc /tmp/bigfile 
         0          0 1073741824 /tmp/bigfile

real    0m45.969s
user    0m45.424s
sys     0m0.424s

MyDesktop:/tmp$ time md5sum /tmp/bigfile 
cd573cfaace07e7949bc0c46028904ff  /tmp/bigfile

real    0m2.520s
user    0m2.196s
sys     0m0.316s

Non è solo una strana condizione limite perché il file è pieno di valori nulli, vedo la stessa differenza nelle prestazioni anche se il file è pieno di dati casuali o è un file di testo.

(questo è su Ubuntu 13.04, 64 bit)

Quindi sono andato alla fonte e sembra che la lentezza sia nella gestione dei caratteri a doppio byte. In sostanza, per ogni personaggio letto, deve chiamare mbrtowc()per provare a convertirlo in un carattere largo, quindi quel carattere largo viene testato per vedere se è un separatore di parole, un separatore di linea, ecc.

In effetti, se cambio la mia LANGvariabile locale da quella predefinita en_US.UTF-8(UTF-8 è un set di caratteri multibyte) e la imposto su " C" (semplice set di caratteri a byte singolo), wcè in grado di utilizzare le ottimizzazioni a byte singolo, che accelera notevolmente, impiegando solo un quarto di tempo rispetto a prima.

Inoltre, deve controllare ogni carattere solo se sta contando word ( -w), line length ( -L) o character ( -m). Se sta eseguendo solo conteggi di byte e / o righe, può saltare l'ampia gestione dei caratteri e quindi funziona in modo estremamente rapido, più veloce di md5sum.

Ho eseguito attraverso gprof, e le funzioni che vengono utilizzati per gestire i caratteri multibyte ( mymbsinit(), mymbrtowc(), myiswprint(), ecc) che occupano circa il 30% del tempo di esecuzione da solo, e il codice che passi attraverso il buffer è molto più complessa perché deve gestire passaggi di dimensioni variabili attraverso il buffer per caratteri di dimensioni variabili, nonché riempire eventuali caratteri parzialmente completati che coprono il buffer all'inizio del buffer in modo che possa essere gestito la volta successiva.

Ora che so cosa cercare, ho trovato alcuni post che menzionano la lentezza utf-8 con alcune utilità:

/programming/13913014/grepping-a-huge-file-80gb-any-way-to-speed-it-up http://dtrace.org/blogs/brendan/2011/12/08 / 2000x-prestazioni-win /

Solo un'ipotesi ma stai paragonando le mele alle arance rispetto a ciò che wcsta facendo rispetto a ciò che md5sumsta facendo.

Compito di md5sum

Quando md5sumelabora un file, apre semplicemente il file come flusso e quindi avvia l'esecuzione del flusso attraverso la funzione checksum MD5 che richiede pochissima memoria. Essenzialmente associato a I / O della CPU e del disco.

compito di wc

Quando wcviene eseguito, sta facendo molto di più, quindi analizza il file un personaggio alla volta. Deve effettivamente analizzare la struttura del file, le linee alla volta, determinando dove si trovano i confini tra i caratteri e se si tratta di un limite di parole o meno.

Esempio

Pensa alle seguenti stringhe e al modo in cui ciascuno degli algoritmi dovrebbe spostarsi mentre le analizza:

“Hello! Greg”
“Hello!Greg”
“Hello\nGreg”
“A.D.D.”
“Wow, how great!”
“wow     \n\n\n    great”
“it was a man-eating shark.”

Per MD5, si muove banalmente attraverso queste stringhe un personaggio alla volta. Perché wcdeve decidere cosa è un limite di parole e linee e tenere traccia del numero di occorrenze che vede.

Discussioni aggiuntive sul wc

Ho trovato questa sfida di codifica del 2006 che parla dell'implementazione wcin .NET. Le difficoltà sono piuttosto evidenti se si guarda ad alcuni degli pseudo codici, quindi questo potrebbe aiutare a iniziare a fare luce sul perché wcsembra essere molto più lento di altre operazioni.