From: stern@mble.philips.be
Newsgroups: comp.compression
Subject: Re: PKLITE, LZEXE and DIET comparedCLOSE
Date: 6 Apr 92 11:44:55 GMT
Followup-To: comp.compression
Organization: MBLE , Brussels, Belgium

In article <2310@accucx.cc.ruu.nl>, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
> Comparission between PKLITE, DIET and LZEXE.
> 
> COMPRESSION (subset of MS-DOS 5.0 files, 29 ones)
> ===========
>           floppy disk                hard disk
> program   file size  cluster usage   file size  cluster usage
> NONE      589223     604140          589223     696320
> PKLite(3) 378093     390144          378093     483328
> DIET      368878     384000          408191     466944 (1)
> LZEXE     381772     393216          381772     475136
> 
> PKZIP 1.93a -ex                      375210
> ARJ 2.30NG -jm                       374102
> 
> SPEED (486/33)
> =====
>           compression   decompression (2)
> PKLite    25 sec         7.58 sec
> LZEXE     18 sec        12.75 sec
> DIET      14 sec         9.45 sec
> 
> PKZIP     11 sec
> ARJ       12 sec
> 
> (1) DIET does not compress a file if this does not save harddisk space
>     (compressed file needs less clusters than origional)
> (2) single 90k testprogram decompressed 108 times with "mini-decompressor"
> (3) The unregistered edition of PKLite was used (they charged our credit
>     card ages ago but stil no program :-()
> (*) None of the files contained any kind of overlays.
> 
> Comclusions (JMHO):
> 
> DIET does best at saving disk space. It is slower at decompression but
> even on a 12MHz AT this is hardly noticable for most files. To me DIET
> seems the best choice. A disadvantage used to be PKLite profesional has
> an irriversible compression option but a program to reverse it anyway is
> available almost anywhere. It is a bit annoying that DIET does not compress
> a file if it does not save HD space. In most cases this is smart but if the
> file has to be distributed it can be annoying.
> What fasinates me most is the small difference between the archivers and
> the exe compressors. DIET does even better than the archivers!
> 
> 
> Nico de Vries (nevries@cc.ruu.nl  NEW ADRESS!)              
> 
> #include <std disclaimer & my personal opinion.h++>             - O   Don't
> Complaints about my spelling to DEV/NUL please.                  |    worry,
> This is a private (ACCU) acount and I don't speak for BITECH.   \_/   be happy!
> 
> "Save WOOD. Print on recycled paper. (You will get used to the gray, realy!)"

Here are the result of a one-file comparing test I did;
the file is the MAKE.EXE from the Borland C++ 2.0
I ran the exec file automatically a lot of times (with no real execution)
on a 33-MHz 386DX from a RAM-disk.

PKLITE 1.13, LZEXE 9.1, DIET 1.20 (not resident)

                  Normal file         diet            lzexe          pklite
size                 41147           24324            24837          24187
exec time            19''            55''             34''           33''

Did I miss something to have a so bad decompression time with diet ?

-----------------------------------------------------------------------------
       Marc Stern  <stern@mble.philips.be>

  ***  Theory is when we know everything but nothing goes right.      ***
  ***  Practice is when everything goes right but nobody knows why.   ***
  ***  Here, we have an harmonious mix between theory and practice:   ***
  ***        nothing goes right and nobody knows why.                 ***
Newsgroups: comp.compression