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!