bphlpt wrote:size doesn't matter
How dare you say that on Valentine's day!! 
I compressed 6 sets of archives based upon the nine latest major DP; 1) using the mainstream settings suggested by mr_smartepants - LZMA, 32, 256, 512
2) LZMA, 48, 128, 512 3) LZMA, 64, 96, 512 4) LZMA2, 32, 256, 512 5) LZMA2, 48, 128, 512 6) LZMA2, 64, 96, 512
I used CDCheck to generate SHA1 CRC hash files to be archived in each individual pack & noted the time archiving took. This was done in the presence of antivirus/antispy products, which may taint comparisons with other systems, yet valid to show the relative performance for this individual system of differing settings. Anything out of the ordinary is noted as well. All file sizes will be noted in KiloBytes, and time will be noted in minutes & seconds.
LZMA --> 1) final size(Sf)=812850KB; time(Tc)=48:08 2) Sf=804243; Tc=37:35 3) Sf=797617; Tc=35:36
LZMA2 --> 4) Sf=808577; Tc=47:37 5) Sf=800185; Tc=37:44 6) Sf=793677; Tc=35:27
On the first system (s775 P4-3GHz-HT Prescott-2M, 3.3GB), decompression testing was done across two partitions on the same drive. The files 7-zip32.dll, un7zip.exe, & un7zip.ini were located in the folder C:\temp\. The 7-zip32.dll was swapped with the potential update when appropriate.
un7zip "D:\... ? ...\LZMA2 examples\LZMA2_64-96-512\*.7z" c:\temp\tmp\ c:\temp\error.log
Afterwards all decompressed files were verified against the SHA1 CRC hash files previously generated. Time consuming, yes, yet very worthwhile, IMHO. Time of decompression (Td) was calculated from the resulting error.log generated by un7zip.exe. After decompression & CRC-checking was finished, I deleted the resulting files in C:\temp\tmp\ & emptied the recycle bin & paused for 5 seconds at a minimum.
For a baseline comparison, i decompressed the previously mentioned archives using the current v4.57 of 7-zip32.dll.
LZMA --> 1) Td=5:29 (CRC-OK) 2) Td=5:20 (CRC-OK) 3) Td=5:23 (CRC-OK)
LZMA2 --> 4) not compatible (all files 0KB) 5) not compatible (all files 0KB) 6) not compatible (all files 0KB)
On the second pass, i substituted the 7-zip32.dll v9.20.0.2 and repeated the same procedure. One item of note; the progress-bar seems to want to do the "Hokey-Pokey" on larger archives between about 5 & 25%. This seems to merely be a cosmetic issue.
LZMA --> 1) Td=4:45 (CRC-OK) 2) Td=4:53 (CRC-OK) 3) Td=4:51 (CRC-OK)
LZMA2 --> 4) Td=4:25 (CRC-OK) 5) Td=4:15 (CRC-OK) 6) Td=4:19 (CRC-OK)
Note that decompression with the newer 7-zip32.dll takes about 13.3% less time with existing archives. This increases to 19.4% with it's LZMA2 counterpart. Number 5 saw decreases of about 22.5% (Need Input!)
TM
On an old laptop with a 1GHz Tualatin (512K cache) with 256MB (SpeedStep enabled) & v4.57 of 7-zip32.dll. This machine has no antivirus nor antispy program for obvious reasons. The archives resided upon a portable DVD+RW drive hooked up to a PCMCIA USB2.0 card.
LZMA --> 1) Td=9:10 (CRC-OK) 2) Td=9:09 (CRC-OK) 3) Td=9:10 (CRC-OK)
LZMA2 --> 4) not compatible (all files 0KB) 5) not compatible (all files 0KB) 6) not compatible (all files 0KB)
The second run used v9.20.0.2 of 7-zip32.dll.
LZMA --> 1) Td=8:47 (CRC-OK) 2) Td=8:34 (CRC-OK) 3) Td=8:45 (CRC-OK)
LZMA2 --> 4) Td=10:11 (CRC-OK) 5) Td=9:45 (CRC-OK) 6) Td=8:56 (CRC-OK)*
* This pass revealed an Access Violation either before or during decompression of
DP_Chipset (the first archive processed). CRC-checking revealed that all files were copied in their entirety.
A subsequent pass failed to reveal the same error. A cosmic ray may have passed through a memory cell;
notwithstanding, it is truly a Dark Matter to me!
As you can see, i'm not getting massive amounts of time consumed by decompression on this legacy system, despite it's lowly memory capacity. Perhaps it is not legacy-enough? I will venture to recreate mr_smartepants results from a year and a half ago when decompression took over an hour. This will have to wait a couple of days, though. By that time i should have some results testing with SAD2 & DP_BASE!
Last edited by TechDud (2012-02-15 19:06:07)
