From relay1.cs.kiev.ua!adamua!lvvhqua!lvvhq.adam.kiev.ua!lvv Fri Oct 01 23:26:53 1993
Received: by softp.kiev.ua (UUPC/@ v5.09gamma, 14Mar93);
          Fri,  1 Oct 1993 23:26:52 +0300
Received: by relay1.cs.kiev.ua; Thu, 30 Sep 93 11:44:27 +0200
Received: by adam.kiev.ua; Thu, 30 Sep 93 12:39:09 +0300 (UKR)
Received: by lvvhq.adam.kiev.ua (UUPC/@ v5.09gamma, 14Mar93);
          Wed, 29 Sep 1993 13:34:17 +0200
To: bnn@softp.kiev.ua
Message-Id: <AAvANgiKp2@lvvhq.adam.kiev.ua>
Organization: Lvv Lab
From: Leonid Volnitsky <lvv@lvvhq.adam.kiev.ua>
Date: Wed, 29 Sep 93 13:34:17 +0200
Subject: for SP
X-Mailer: BML [MS/DOS Beauty Mail v.1.36]
Lines: 152
Status: RO


X-Listname: Zip/UnZip Bug Reports <Zip-Bugs@WKUVX1.BITNET>
Warnings-To: <>
Errors-To: IZip-Mgr@WKUVX1.BITNET
Date: Tue, 28 Sep 1993 00:16:08 +0100
From: Kai Uwe Rommel <rommel@ars.muc.de>
Reply-To: Kai Uwe Rommel <rommel@ars.muc.de>
Subject: zip vs. arj benchmark
To: zip-bugs%WKUVX1.bitnet@ULKYVM.LOUISVILLE.EDU
X-Mailer: ELM [version 2.3 PL11] for OS/2

Newsgroups: comp.os.os2.apps
Subject: Re: ARJ ? (includes benchmark)
In article <27o189$ikt@bigboote.WPI.EDU> ear@bigwpi.WPI.EDU (Mr. Neat-O [tm]) wr
ites:
>In article <27bv0v$of2@nuscc.nus.sg>, Sriram <swknasri@leonis.nus.sg> wrote:
>>I am curious ... but with zip and unzip for OS/2 available,
>>whats the special advantage of ARJ (other than deal with
>>ARJ files)?
>
>ARJ is faster than zip, typically offers better compression, and also
>makes a great backup program for floppy users with its multivolume features.
>It also has fairly detailed help info built into the executable and only
>requires one executable for both compression and decompression.

I wish you would have posted if you actually benchmarked ARJ and ZIP
or if your statement is just hearsay. It seems to be commonly "known"
that arj is faster but is it really true?

I *have* benchmarked zip 2.0.1 vs. arj 2.41 and got the opposite
impression. :-)

Of course I am biased towards zip because I'm member of the Info-ZIP
team but see my benchmark below, you can easily do the same test to
see yourself.

Other than the speed and compression ratio, there are of course also
differences in the user interface. Arj provides a lot of options and
has good multi volume support while zip has none.

[For those who don't know yet: zip 2.0.1 is a bugfix release for zip
2.0 and fixes the serious OS/2 EA bug in zip 2.0. You can get the
source from either ftp.uu.net:/pub/archiving/zip or
garbo.uwasa.fi:/unix/arcers.  Executables are available from
ftp.cdrom.com and from ftp.informatik.tu-muenchen.de:/pub/comp/os/os2.
Both of these sites have the source code too. Note that on
ftp.cdrom.com, the incoming directory has two copies of the source
code, the newer one is OK.]

Now let's go on to the benchmark:

* machine used: 486DX 50MHz EISA system, running OS/2 2.1

* benchmarked programs:

- Info-ZIP zip 2.0.1, compiled with gcc 2.4.5 (emx 0.8g) as a native
  32-bit OS/2 2.x application. This version includes some 386 assembly
  language code for the most time critical part too. This is the
  executable from the zip 2.0.1 for OS/2 2.x distribution.
- ARJ 2.41, a DOS program, running in an OS/2 2.1 DOS session.
- PKZIP 2.04, also pure DOS program, running in an OS/2 2.1 DOS session.

I have added PKZIP to the benchmark for comparison.

The benchmark: compression of 14 of the files from the Calgary Text
Compression Corpus (according to the comp.compression FAQ, the files
paper[3-6] were omitted).

All three programs were run twice, once with default compression and
once with maximum compression. See the resulting sizes and total run
times below:

a) default compression:

           size       zip       arj     pkzip
version:             2.0.1     2.41     2.04g
options:
          ------    ------    ------    ------
bib       111261     35041     36028     35821
book1     768771    313352    319068    315999
book2     610856    206663    210333    209061
geo       102400     68471     68980     68917
news      377109    144817    146861    146010
obj1       21504     10300     10314     10311
obj2      246814     81608     81955     81846
paper1     53161     18552     18644     18624
paper2     82199     29728     29929     29795
pic       513216     56420     55104     54188
progc      39611     13251     13410     13340
progl      71646     16249     16414     16227
progp      49379     11222     11293     11248
trans      93695     18961     20073     19691
                                        ------
total    3141622   1024635   1038406   1031078

run time            38.53s    58.80s    35.22s

b) maximum compression:

           size       zip       arj      pkzip
version:             2.0.1     2.41      2.04g
options:              -9        -jm       -ex
          ------    ------    ------    ------
bib       111261     34878     36020     35126
book1     768771    312257    318835    312490
book2     610856    206134    210260    206513
geo       102400     68392     68916     68706
news      377109    144377    146845    144545
obj1       21504     10297     10315     10306
obj2      246814     81064     81789     81132
paper1     53161     18518     18646     18531
paper2     82199     29642     29910     29568
pic       513216     52359     53342     52409
progc      39611     13237     13408     13341
progl      71646     16140     16389     16122
progp      49379     11162     11270     11200
trans      93695     18838     20055     19462

total    3141622   1017295   1036000   1019451

run time            67.81s    81.90s    62.19s

In both benchmarks, zip 2.0.1 had the best compression of all three
programs (although differences are not very big). With only one
exception (the pic file at normal compression), zip compressed better
than arj on all individual files too, not only on the total.

As a side note: for all three programs, one does not see a large
benefit from using maximum compression instead of default compression.

Also in both benchmarks, zip 2.0.1 was much faster than arj 2.41
(especially at normal compression) and less than 10% slower than pkzip
2.04.


Kai Uwe Rommel

--
/* Kai Uwe Rommel                                      Muenchen, Germany *
 * rommel@ars.muc.de      CompuServe 100265,2651   Phone +49 89 723 4101 *
 * rommel@informatik.tu-muenchen.de                  Fax +49 89 324 4524 */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams



---
Leonid Volnitsky             Ukraine |
                            2:463/44 |      Practice random kindness and
                      +7-044-5184889 |         sensless acts of beauty
  lvv%lvvhq.adam.kiev.ua@ussr.eu.net |

