jeśli musisz spakować wiele rzeczy, wykorzystanie potężnej ilości rdzeni i wątków nowoczesnych CPU wydaje się oczywiste, chyba że… narzędzia, których używasz, w ogóle nie biorą pod uwagę dostępności takiego luksusu. i wszystko co robisz, robisz w oparciu o jeden rdzeń/wątek.
ponieważ spędzam ostatnio dużo czasu głównie w środowisku FreeBSD i MacOS, narzędzia których zwykle używam uruchamiam z linii poleceń terminala.
tak więc, dla każdego użycia gzip - spróbuj użyć pigz, a dla bzip2 - programu pbzip2.
przykładowe użycie pigz:
tar cf - src_files | pigz > OUTPUT_FILE.tar.gz
…albo jako część wbudowanego w tar mechanizmu wykorzystywania zewnętrznych narzędzi kompresujących:
tar --use-compress-program=pigz -cf OUTPUT_FILE.tar.gz src_files
użycie pbzip2 wygląda praktycznie tak samo - tutaj dodatkowo skrócimy przydługie --use-compress-program do -I:
$ tar -I pbzip2 -cf OUTPUT_FILE.tar.bz2 paths_to_archive
zysk na czasie będzie zależny od podsystemu I/O oraz ilości rdzeni/wątków procesora (domyślnie oba zamienniki używają tylko fizycznych rdzeni a nie wątków), ale dla przykładowego zbioru 100+ plików binarnych, czas kompresji spadł mi z 3m53s na 34 sekundy przez prostą podmianę gzip na pigz.
powodzenia w kompresowaniu swoich danych!