Skutecznie kompresuj podobne pliki

11

Często muszę kompresować pliki, które są do siebie bardzo podobne.

Obecnie używam 7Zip, który kompresuje plik 16 GB do 1,2 GB w około 35 minut przy użyciu 8 rdzeni z ustawieniami Ultra.

Wydaje mi się, że większość tego czasu spędza na obliczaniu słownika w celu kompresji. Ponieważ pliki są bardzo podobne, faktycznie używany słownik jest prawdopodobnie podobny.

Czy istnieje narzędzie do kompresji oparte na systemie Windows (7Zip z opcją, której nie znam, lub inne narzędzie), które może zapisać słownik i ponownie użyć zapisanego słownika do kolejnych plików?

Czy istnieje lepszy sposób na rozwiązanie problemu utrzymania współczynnika kompresji podobnego do tego, który mam, przy kompresji znacznie szybciej?

compression

— Eric J.
źródło

5

LZW (LZW) algorytm kompresji jest z natury obliczeniowej, przy czym większość sama praca jest rzeczywiście obliczeniowej słownika. To dosłownie tak działa LZW.

Sam algorytm dodaje jedną nową pozycję słownika dla każdego następnego skanowanego „symbolu”, a zatem podczas każdej iteracji do słownika dodawana jest nowa pozycja. W efekcie słownik staje się skompresowaną kopią pliku, a zatem jest tak naprawdę jedyną rzeczą, dla której kompresja LZW spędza znaczny czas na obliczeniach.

Jeśli użyjesz czegoś takiego jak kodowanie Huffmana , ponowne użycie słownika byłoby rzeczywiście możliwe (kosztem możliwie nieoptymalnego współczynnika kompresji / wielkości). Jednak większość współczesnych algorytmów i narzędzi kompresji używa algorytmu LZW do zwiększenia wydajności i szybkości (kompresja Huffmana wymagałaby dwóch przejść danych [jeden do wygenerowania drzewa / tabeli Huffmana, drugi do faktycznej kompresji danych], podczas gdy LZW można wykonać w pojedyncze przejście).

— Przełom
źródło

1

Czy w przypadku Huffmana i predefiniowanego słownika wymagana byłaby tylko jedna przepustka? Czy istnieją jakieś gotowe narzędzia oparte na Huffmanie, które obsługują zapisane słowniki?

— Eric J.

@EricJ. tak, ze wstępnie zdefiniowanym słownikiem byłoby to kodowanie jednoprzebiegowe. Nie znam żadnego oprogramowania, które mogłoby to zrobić, chociaż osobiście napisałem takie programy. Chociaż nie próbowałem tego narzędzia, wygląda na to, że może to zrobić. Należy jednak pamiętać, że (ponownie, w przeciwieństwie do LZW) do dekodowania strumienia bitów zakodowanego przez Huffmana, nadal potrzebny jest oryginalny słownik do dekompresji danych.

— Przełom

Biorąc pod uwagę wiek tego narzędzia, domyślam się, że jest ono jednowątkowe. Domyślam się, że użycie 1 rdzenia zamiast 8 zrównoważyłoby jakąkolwiek korzyść ze stałego słownika :-( W moim scenariuszu możliwe jest posiadanie słownika dostępnego na drugim końcu (przesyłanie dużych plików między centrami danych).

— Eric J.

2

W przeciwieństwie do algorytmu DEFLATE, LZMA 7-Zip domyślnie stosuje solidną kompresję, która wykorzystuje redundancję między plikami. Będzie to działać z ustawieniami domyślnymi, o ile pliki będą wystarczająco małe.

Przy domyślnych ustawieniach 2 GB dla rozmiaru Solid Block plik 16 GB jest tak naprawdę kompresowany jako 8 oddzielnych porcji.

Jak już powiedział @Breakthorugh, słownik jest generowany w locie. Możesz to zweryfikować empirycznie, ustawiając rozmiar Solid Block na Solid (kompresuj wszystkie pliki jednocześnie) i Non-solid (kompresuj każdy plik osobno).

Zwiększenie rozmiaru bloku bryłowego spowoduje spowolnienie, ale może skutkować znacznie lepszym współczynnikiem kompresji. Na przykład kompresja dwóch identycznych plików spowoduje, że archiwum będzie prawie dwa razy większe z kompresją niestałą.

— Dennis
źródło

1

W moim przypadku kompresuję podobne pliki pojedynczo, przy różnych okazjach. W danym archiwum znajduje się tylko jeden plik o pojemności 16 GB.

— Eric J.

Ach, okej. Źle to zinterpretowałem. Czy stare archiwa są usuwane po utworzeniu nowego? Jeśli nie, czy dopuszczalne jest przechowywanie kilku plików w jednym archiwum? To nie pomoże w szybkości kompresji, ale w zależności od tego, jak bardzo pliki są rzeczywiście podobne, może to pomóc w stosunku.

— Dennis

1

Nieważne, że nie. Aktualizacja solidnego archiwum zajmuje dużo więcej czasu, ale nie powoduje lepszej kompresji.

— Dennis