La decompressione parallela funziona?

In un post precedente , ho provato a scrivere un'utilità di decompressione che utilizza i file di decompressione in parallelo, sulla base del fatto che Rust rende questo tentativo sicuro.

Ecco alcuni risultati delle prestazioni.

Il caso d'uso che mi interessa è decomprimere le build Chromium ASAN ottenibili da qui . Per questi test ho scelto una particolare build, che sembra essere 3.845.117.901 byte.

ripunzipora supporta due modalità: ripunzip file <filename>, e ripunzip uri <URI>. Il primo decomprime semplicemente un file. Quest'ultimo utilizza più richieste di intervalli HTTP per eseguire il download e la decompressione in parallelo. (Le richieste di intervallo sono necessarie a causa della struttura di un file zip: deve leggere le informazioni sulla directory sparse in tutto il file prima che possa iniziare a decomprimere effettivamente il contenuto).

(usando ripunzipSHA ca71fa12e7510b9d48b55ccd6a9dfe051291ca42. Questi risultati non sono stati ripetuti per essere statisticamente validi perché non voglio caricare troppo il server HTTP di origine. Ci sono alcuni cargo criterionbenchmark ufficiali nel progetto, ma non rappresentano adeguatamente la rete del mondo reale condizioni).

Ci sono alcuni risultati interessanti qui!

Prima le buone notizie sulla decompressione dei file: la decompressione di questo file zip su una VM Linux veloce richiede 9 secondi , al contrario della decompressione che richiede 94 secondi. Su una macchina virtuale Windows, sono 52 secondi rispetto ai 165 secondi per 7z.

Tuttavia, questo miglioramento non è universale. Su una VM Linux lenta, ripunzipin realtà è più lenta. Non riesco a spiegarlo completamente - sembra avere qualcosa a che fare con il back-end di archiviazione del sistema VM che fatica a far fronte a molte richieste parallele - forse sono le testine del disco rigido fisico che cercano da qualche parte nel cloud? (Wow. Non mi aspettavo di dover far funzionare questo strumento in modo efficiente per pezzi di metallo vecchio stile.) Non sono sicuro che questa sia la spiegazione, ma sembra avere qualcosa a che fare con le basse velocità di scrittura.

Decomprimendo direttamente da un URI, generalmente vediamo che ripunzipsembra essere limitato dalla larghezza di banda. In senso buono ! Completiamo la decompressione in pochi secondi in più rispetto a quanto sarebbe necessario per scaricare il file zip in primo luogo utilizzando curl, quindi effettivamente otteniamo la decompressione "gratuitamente". Questo non si applica su Windows, forse perché ho usato Chrome per scaricare il file zip ( curlnon era disponibile). Ma la velocità di decompressione è molto più veloce su questa macchina Windows che è ancora vantaggiosa.

Un punto particolarmente interessante è che ripunzip uriè più veloce rispetto ripunzip filealla lenta VM Linux... Immagino che la ricerca delle testine del disco tra il file zip e i file decompressi sia davvero super lenta, mentre la lettura da un server HTTP remoto è in realtà più veloce (!)

Cosa significa questo per Chromies che riproducono bug di sicurezza? Bene, devo impacchettare lo strumento e renderlo disponibile su tutti i nostri ambienti di test, ma nel complesso significa uno o due minuti risparmiati per ogni build di Chromium che dobbiamo scaricare... (purché utilizzi un SSD?) In realtà è importante quando dobbiamo scaricare diverse build, più volte al giorno. Sarà interessante vedere se questi risultati si adattano alle build UBSAN da 36 GB e se questo strumento può anche rendere più veloci alcuni dei nostri sistemi automatizzati. (Penso che scoprirò abbastanza rapidamente se quei sistemi sono supportati da SSD o dischi rigidi ...)

Puoi provare tutto questo con cargo install ripunzip.