Allow 7zip as a zip unpacker and 7z unpacker

[chaos7]

Please allow 7zip as a zip unpacker. Unpacking a zip archive is 7.6x faster with 7zip compared to the TC internal unpacker.

Also, allow 7zip as a 7z unpacker. It is almost 2x faster than the TC internal 7z unpacker.

(More details about TC performance are here: https://www.ghisler.ch/board/viewtopic.php?t=86611)

[petermad]

Hmm, I just tested unpacking a 700 Mb zip file. Unpacking with internal unzip took 13 seconds the first time and 6 seconds the second time. 7-Zip used 36 and 24 seconds for extracting the same file. that is internal unzip being 2.8 to 4 times faster.

[chaos7]

Hmm, I just tested unpacking a 700 Mb zip file. Unpacking with internal unzip took 13 seconds the first time and 6 seconds the second time. 7-Zip used 36 and 24 seconds for extracting the same file. that is internal unzip being 2.8 to 4 times faster.

If you are getting such varied results with the same operation ran twice then something seems wrong with your testing environment. I suggest using a RAM disk for both the source and the target so read/write/cache don't interfere with the results. I also recommend a much larger data size (a few GB with a few thousand files). Make sure you are using the latest 7zip build, and that no other processes are hogging the CPU.

For example, unpacking a Google Photos Takeout ZIP archive of 9GB / 8000 files (4000 jpeg + 4000 json) with the internal TC unzip takes 92 seconds, compared to only 12 seconds with 7zip. Both the source and the target were on a RAM disk. I used TC v.11.56 (x64) and 7z v.25.01 (x64).

[ghisler(Author)]

It's normal that the second time unpacking is much faster, because:
1. Everything is in the cache now, and
2. The background virus scanner skips the files it already scanned before.

Btw, I also don't get such large differences between the internal ZIP unpacker and 7-ZIP. It must be due to specific input files. For example, files which were packed with the checksum at the end (streaming packer) cannot be unpacked with the new much faster internal unpacker and use the old slower unpacker.

[chaos7]

Thank you for the explanation. I have the virus scanner disabled and I use RAM disk, so I am getting quite consistent results with every run. Have you tried this with Google Photos takeout? This is a very common user scenario. It's possible Google Takeout uses streaming packing.

I just tested it again with a 9GB zip from Google Photos Takekout that has 6500 files (half of them jpeg, half json):
- TC internal unpacker: 90 seconds first run, 91 seconds the 2nd run
- 7zip: 13 seconds, 10 seconds

Then I zipped the same files using the TC internal packer, (default compression level: 6). Now unpacking took:
- TC internal unpacker: 26 sec, 26 sec
- 7zip: 46 sec, 54 sec but it's showing "Warning: Headers Error"

Finally, I packed the same files into a ZIP in TC configured with 7zip as the packer (default compression: 6). Unpacking this archive took:
- TC internal unpacker: 12 sec, 12 sec
- 7zip: 12 sec, 13 sec

Is there anything that can be done to speed up the internal unpacker in the first scenario?
Is "Headers Error" a known issue for ZIPs created by the TC internal packer?

[ghisler(Author)]

Is there anything that can be done to speed up the internal unpacker in the first scenario?

No, it really looks like the file was created via streaming. The new much faster method needs to know the size of the packed data beforehand, which is unknown when doing streaming. I will have a look at the Google Takeout files, maybe there is a workaround.

Is "Headers Error" a known issue for ZIPs created by the TC internal packer?

No, I never had this reported, but I can reproduce it with archives >4GB. I'm not aware of any problems with TC archives, they should fully follow the standard. The Explorer and WinZip don't report any errors. I only get this warning when right clicking on it and choosing 7-Zip -> Verify errors. When I open it in 7-zip and select all files and then verify, I do not get any errors. Also all files unpack correctly.