Prestazioni di loop vs espansione

Hai bisogno di suggerimenti di esperti sul confronto di seguito:

Segmento di codice tramite loop:

for file in `cat large_file_list`
do
    gzip -d $file
done

Segmento di codice mediante semplice espansione:

gzip -d `cat large_file_list`

Quale sarà più veloce? Devono manipolare un set di dati di grandi dimensioni.

complicazioni

Quanto segue funzionerà solo a volte:

gzip -d `cat large_file_list`

Tre problemi sono (nella bashe nella maggior parte delle altre shell tipo Bourne):

1. Non funzionerà se un nome di file contiene una scheda spazio o caratteri di nuova riga (supponendo che $IFSnon sia stato modificato). Ciò è dovuto alla divisione della parola della shell .

2. Può anche fallire se un nome file contiene caratteri glob-active. Questo perché la shell applicherà l' espansione del nome percorso all'elenco dei file.

3. Fallirà anche se i nomi dei file iniziano con -(se POSIXLY_CORRECT=1questo vale solo per il primo file) o se esiste un nome qualsiasi -.

4. Non funzionerà anche se ci sono troppi nomi di file per adattarsi a una riga di comando.

Il codice seguente è soggetto agli stessi problemi del codice sopra (tranne il quarto)

for file in `cat large_file_list`
do
    gzip -d $file
done

Soluzione affidabile

Se hai large_file_listesattamente un nome file per riga e un file chiamato -non è tra questi, e sei su un sistema GNU, allora usa:

xargs -rd'\n' gzip -d -- <large_file_list

-d'\n'indica xargsdi trattare ogni riga di input come un nome file separato.

-rdice di xargsnon eseguire il comando se il file di input è vuoto.

--dice gzipche i seguenti argomenti non devono essere trattati come opzioni anche se iniziano con -. -da solo verrebbe comunque trattato -invece del file chiamato -però.

xargsinserirà molti nomi di file su ciascuna riga di comando ma non così tanti da superare il limite della riga di comando. Ciò riduce il numero di volte in cui un gzipprocesso deve essere avviato e quindi lo rende veloce. È anche sicuro: i nomi dei file saranno anche protetti dalla suddivisione delle parole e dall'espansione del percorso .

Dubito che importerebbe molto.

Vorrei usare un ciclo, solo perché non so quanti file sono elencati nel file elenco e non (in genere) so se qualcuno dei nomi di file ha spazi nei loro nomi. La sostituzione di un comando che genererebbe un elenco di argomenti molto lungo può causare un errore "Elenco argomenti troppo lungo" quando la lunghezza dell'elenco generato è troppo lunga.

Il mio ciclo sarebbe simile

while IFS= read -r name; do
    gunzip "$name"
done <file.list

Ciò mi consentirebbe inoltre di inserire comandi per l'elaborazione dei dati dopo il gunzipcomando. In effetti, a seconda di cosa siano effettivamente i dati e cosa debba essere fatto con essi, potrebbe anche essere possibile elaborarli senza salvarli su file:

while IFS= read -r name; do
    zcat "$name" | process_data
done <file.list

(dov'è process_datauna pipeline che legge i dati non compressi dall'input standard)

Se l'elaborazione dei dati richiede più tempo rispetto alla loro decompressione, la questione se un ciclo sia più efficiente o meno diventa irrilevante.

Idealmente , preferirei non lavorare su un elenco di nomi di file, e invece utilizzare un modello globbing di nome file, come in

for name in ./*.gz; do
    # processing of "$name" here
done

dove ./*.gzè un modello che corrisponde ai file pertinenti. In questo modo non dipendiamo dal numero di file né dai caratteri utilizzati nei nomi dei file (possono contenere righe o altri caratteri spazi bianchi o iniziare con trattini, ecc.)

Relazionato:

• Comprensione "IFS = read -r line"

Di questi due, quello con tutti i file passati a una singola chiamata gzipè probabilmente più veloce, proprio perché è necessario avviarlo solo gzipuna volta. (Cioè, se il comando funziona affatto, vedi le altre risposte per le avvertenze.)

Ma vorrei ricordare la regola d'oro dell'ottimizzazione : non farlo prematuramente.

1. Non ottimizzare questo genere di cose prima di sapere che è un problema.

   Questa parte del programma richiede molto tempo? Bene, decomprimere file di grandi dimensioni potrebbe essere, e dovrai farlo comunque, quindi potrebbe non essere così facile rispondere.

2. Misurare. Davvero, è il modo migliore per essere sicuri.

   Vedrai i risultati con i tuoi occhi (o con il tuo cronometro) e si applicheranno alla tua situazione che potrebbero non avere risposte casuali su Internet. Inserisci entrambe le varianti negli script ed esegui time script1.sh, e time script2.sh. (Fallo con un elenco di file compressi vuoti per misurare la quantità assoluta dell'overhead.)

Quanto è veloce il tuo disco?

Questo dovrebbe usare tutte le tue CPU:

parallel -X gzip -d :::: large_file_list

Quindi il tuo limite sarà probabilmente la velocità del tuo disco.

Puoi provare ad adattarti con -j:

parallel -j50% -X gzip -d :::: large_file_list

Questo eseguirà metà dei lavori in parallelo come il comando precedente e stresserà il disco di meno, quindi a seconda del disco questo può essere più veloce.