Mam skompresowany plik PIXZ (poziom -9) zawierający około 4000 plików (uporządkowanych, podobnie jak strony w książce): skompresowany rozmiar to ~ 670M. Obecnie programowo uzyskuję dostęp do tych plików w standardowy sposób, tj
pixz -x <compressed_file_name> < tarball.tpxz | tar x -O
Na podstawie używanych metryk timewyodrębnienie pliku zajmuje średnio 1,7 sekundy. Ponieważ jest to część procesu programistycznego, chciałem skrócić ten czas, jeśli to możliwe, więc pomyślałem o podzieleniu tpxzarchiwum na trzy mniejsze ~ 200 milionów segmentów (każdy zawierający ~ 1000 plików), z oczekiwaniem, że pixz -xbędzie działać znacznie szybciej w stosunku do dowolnego jeden z tych trzech segmentów w porównaniu z oryginałem ~ 600M. (Potrafię przewidzieć, który z trzech segmentów zawiera plik wymagany dla procesu).
Jednak ku mojemu zdziwieniu, pomiary czasu względem 200M segmentów są identyczne jak w przypadku oryginału: wyszukiwanie / dekompresja nadal trwa średnio 1,7 sekundy. Ponieważ jest to sprzeczne zarówno z intuicją, jak iz wynikami w ekstremalnym przypadku - wyszukiwanie / dekompresja w -9skompresowanym pliku tar zawierającym pojedynczy plik kończy się w trywialnym czasie - jestem ciekawy, dlaczego moja strategia segmentacji zawiodła i czy istnieją jakieś inne strategie ludzie mogą zalecić poprawę wydajności pixzwyszukiwania dużych plików: 1,7 sekundy jest z pewnością dopuszczalne, szczególnie biorąc pod uwagę oszczędność kosztów przechowywania, ale byłoby miło szybciej.
Jeśli jest jakiś próg wielkości archiwum i / lub numeru archiwum, po przekroczeniu którego czas ukończenia pozostaje w przybliżeniu stały dla pixzzadań wyszukiwania / dekompresji, byłoby to interesujące i przydatne, aby to wiedzieć, więc z góry dziękuję za wszelkie porady.