Strange progress bar behavior
A free file archiver for extremely high compression
Brought to you by:
ipavlov
WinRAR users spotted that 7zxa.dll pushes progress bar before actually extracting files (see Ru.Board topic). The behavior has changed between versions 16.04 and 18.03.
I have extracted nVidia driver package 341.92-notebook-win8-win7-32bit-international.exe
with 7zG 18.06 x86. The first block is compressed with LZMA2:26
. If I press Pause before ~26%, no files are present in the target directory. Either 7-Zip uses aggressive write caching, or the progress bar is connected to LZMA2 chunk extraction, not to files. Is that a bug?
Probably it's multithreading.
Each thread decompresses some part of data and reports to progress. But it must wait all previous parts (that must be decomprerssed by another threads) before real data writing.
Also multithread LZMA2 decoder can read data to internal buffers to search independent parts of lzma2 stream for multithreading. It can look slow, if filesystem is slow (HDD), and file data is not in cache.
All such things depend from dictionary size of LZMA2. It can create larger pauses for big dictionary.
7-Zip expects 256 MiB LZMA2 chunk for 64 MB dictionary.
Last edit: Igor Pavlov 2018-12-31
Is it expected to report progress before writing to the filesystem? The users in the mentioned forum say that the progress immediately jumps to 30%, and only then actual extraction happens.
Writing is simple operation and processing (compression or decompression) is difficult operation. So 7-Zip tries to show progress of difficult operation.
I call "Test Archive" command for that nvidia file in WinRAR and 7-Zip. And progress in 7-Zip looks OK.
About WinRAR.
It can use different ways to show progress:
1) to track archive file input reading.
2) to track extracted file output writing
3) show progress values reported by 7-Zip
Maybe WinRAR switches from one way to another at some point. I don't know.
Last edit: Igor Pavlov 2019-01-02