Problem with LZMA 2 codec

[Skymmer]

Here's the deal. I've done a brief test with v2.79 (Jun 21 2007 [int: 20250] [eng: 20907]) and v2.90.1 (Jul  7 2008 [int: 20282] [eng: 20907]).
The command line is following:

Code Select Expand

timer pec2.exe Test9.exe /Wl:No /Tm:No /Ri:N /Cl:9 /Dt:Small /Asd:Yes /Cic:No /Mc /Nb /Tl:Yes /Ko:No /Ch:pec2codec_lzma2.dll /Lch:pec2codec_aplib.dll /Lh:pec2ldr_reduced.dll
Here is the table for 6 different files with timings and resulting sizes.


                    v2.79 (time\size)       v2.90.1 (time\size)
-------------------------------------------------------------------
ZBrush3.exe       |113.547 \ 3422604   190.844 \ 3422588
Traktor3.exe      |210.141 \ 3177396   269.453 \ 3177380
PS2.exe           | 60.750 \ 5036320    83.156 \ 5036304
TheBat38.exe      | 47.938 \ 3650112    62.438 \ 3650096
AVCataloger.exe   | 24.829 \ 970624    40.281 \ 970608
FreePascal.exe    | 14.531 \ 1853656    19.906 \ 1853640
-------------------------------------------------------------------

Interesting thing that the all files for v2.90.1 are always 16 bytes smaller then for v2.79 but look at the processing time!
Average degradation is 44% and the maximum spotted is 68% (for the ZBrush3.exe).
Don't you think is a little bit ehhh... suspicious ? Anyway, thanks for keeping up the good work.

[Jeremy Collake]

Thanks for running these tests. The increase in processing time is due to changes in the LZMA codec.

What's going on? Analysis and test compressions to determine the most optimal LZMA compression parameters  .. one of the unique features of PECompact. I hadn't publicly revealed that I do this yet, but since you ask -- there it is

So, while it is intentional, you are right that it appears on the tested executables that the extra test time doesn't make much of a difference. Perhaps I should further tweak it to tune down compression times at higher compression levels.

Whether or not its 'worth it', I don't know for certain, but that's what the compression level parameter is for (/cl). Lowering the compression level should decrease the time to compress and probably not hurt the compression ratio in most cases. So, to return to v2.79 behavior, setting the compression level to '3' or '5' should do it. In fact, at the default compression level, it may behave identically to v2.79 -- I'd have to go and check the commit logs to find out exactly what tweaks I made.

As a side note to readers: The compression time and compression level do not directly affect decompression speed. However, in some cases, a higher compression ratio can slightly increase decompression speed because there is a smaller compressed data stream to work with. So, compression time/ratio is inversely related to decompression speed, if any relation is to be drawn.

Thanks,
Jeremy