#580 ZPAQ uses no CPU (list/browse)

ZPAQ is slow and uses no CPU.(6% Max) Tested on Windows (Wine), portable and GTK2 versions.
Does not appear to be the case from terminal ZPAQ 715.( 100% CPU, all threads)
Issue happened also several years ago but was fixed
All the best

[Giorgio Tani]

Hello, in my test Zpaq was able to saturate the CPU (8 core test machine) both when launched from console and from graphic UI - which generates the same command - used at default compression level on 300 MB test input on SSD disk.

Please note Zpaq will likely not saturate CPU / threads on following conditions:
1 - compression level set to 1 or 2, those levels use lightweight LZ77 algorithm without employing Context Mixing or Burrows–Wheeler transform
2 - small input size, even if 3 or higher compression level is used, because the input will be treated as a single block in a single thread (CM and BWT needs more data context), so even if a single core will be at 100%, the overall CPU usage will be reported quite low on modern machines - if I recall correctly this was the case of the issue reported a few years ago
3 - less likely, but possible, slow input source (slow mechanical disk, many small files, fragmented data, slow network unit) will not provide data enough quickly to the compressor to saturate the CPU - but once the data gets cached and the test run following times the input will be fast enough.

[Anonymous]

Hi Giorgio

Many thanks for the quick input, i can clarify the following bits.

The ZPAQ is around 600mb, made up from many many small highly compressible files.

It is ultra level compressed.

It is running both from console (console is the download direct from Matt Mahoney) and UI on a modern SSD (Samsung evo 960) Ryzen 1700x, 8 cores 16 threads .

As I mentioned, the console command pretty much saturates the CPU.

At first I did think it was due entirely to mechanical drive speed (On compression) however; once HDD had stopped, it continued at 6% for many hours after. Now moved over to SSD (As it is small) the decompression appears to be the same

Greatly appreciate your fantastic software, and have been using it for some time. First time using ZPAQ

[Giorgio Tani]

PeaZip uses Zpaq 7.15 which is the last version available on Matt Mahoney's website.
Windows 32 and 64 bit binaries are the same featured in the 7.15 package on Matt Mahomey's website, while Linux ones were compiled from sources.
To replicate the issue it can be useful to me to know what are the binaries are you using for the two test (GUI, and console), and to have an example of the command lines launched for the two test - in PeaZip the command line is accessible from "Console" tab, showing the exact command that is being executed.

[Anonymous]

A little more info has come to light.
It appears to be only in the case of opening/browsing the archive.
(It did however as mentioned above, use 6% CPU for several hours after finishing reading on mechanical HDD)

Straight extracting does peg the CPU at 100% ('/usr/share/peazip-gtk2-bin/res/zpaq/zpaq' x '/mnt/NAS/Backup/2019.zpaq' -to '/mnt/NAS/Backup/2019/' (Moved off my SSD for now) as does the compression ('/usr/share/peazip-gtk2-bin/res/zpaq/zpaq' -method 5 a '/mnt/NAS/Backup/VMs.zpaq' '/mnt/NAS/Backup/VMs/')

[Giorgio Tani]

Thank you for tracking the issue further, I'll do more test on "l" (list) command on zpaq, which is the one performed when browsing the archive - and on further code executed on GUI to display the list output.
Does l list command perform poorly (low cpu usage, and no response) from console too on your test machine?

[Anonymous]

Hi Giorgio,

Thanks for getting back. I can confirm that performance is poor with the list command from console. Tried many combinations of switches including the following '-threads, -noattributes, -force, -summary' all terible CPU usage