Eu tenho um tarball compactado em PIXZ (nível -9 ) contendo cerca de 4.000 arquivos (ordenados, como páginas em um livro): o tamanho compactado é ~ 670M. Atualmente, estou acessando programaticamente esses arquivos usando o modo padrão, ou seja,
pixz -x <compressed_file_name> < tarball.tpxz | tar x -O
Com base nas métricas que usam time , a extração do arquivo leva em média 1,7 segundo. Como isso faz parte de um processo programático, eu queria diminuir esse tempo se possível, então pensei em dividir o tpxz archive em três segmentos menores de ~ 200M (cada um contendo ~ 1000 arquivos), com a expectativa de que pixz -x correria significativamente mais rápido contra qualquer um desses três segmentos do que contra o original de ~ 600M. (Eu posso prever qual dos três segmentos contém um arquivo necessário para o processo.)
No entanto, para minha surpresa, as métricas de tempo nos segmentos do 200M são idênticas às do original: a pesquisa / descompactação ainda é executada em média 1,7 segundos. Como isso está em desacordo tanto com a intuição quanto com os resultados em um caso extrema - lookup / descompactação com um tarball -9 -compressed contendo um único arquivo é concluído em um período de tempo trivial - estou curioso para saber por que minha estratégia de segmentação falhou e existem outras estratégias que as pessoas podem recomendar para melhorar o desempenho de pixz de pesquisas em arquivos largos: 1,7 segundo é certamente aceitável, especialmente considerando o que você economiza em custos de armazenamento, mas um tempo mais rápido seria bom.
Se houver algum tamanho de tarball e / ou número de arquivo morto além do qual o tempo de conclusão permanece aproximadamente constante para pixz pesquisa / descompactação, seria interessante e útil saber disso, então agradecemos antecipadamente por qualquer conselho.
Tags compression tar