Re: tech proposal to make manoj somewhat happy.
Gavin Lewis <zif@kalifornia.com> writes:
> On Sun, Jul 26, 1998 at 01:40:28PM -0500, Petra, Kevin J Poorman wrote:
> > deffinatly... can you think of a way to time the decompression time of say
> > a 5meg directory ... wonder which has the best compression method...
> > something for me to look into.
> I took the 2.0.35 kernel tree (with a bunch of object files, it's not
> make cleaned), and tested decompression with .tar.gz and .zip using
> tar, gzip, and unzip from Debian. It's roughly 10 megs compressed.
> My machine is an AMD K5-P166. Here are the results:
> (Using time. User and sys are the entries we're interested in.
> I don't believe waiting for the hard disk is included in user/sys.)
> tar zxvf:
> real 0m51.094s
> user 0m11.470s
> sys 0m9.220s
> zip:
> real 0m45.374s
> user 0m10.060s
> sys 0m5.240s
>
> It appears that zip is slightly faster, at least for this example.
What's the standard deviation? (I.e. you need more runs for the
numbers to mean anything. It looks like you are running tar with a
cold disk cache and zip with a warm one.) The extra time for tar may
be from restoring extra metainformation that zip doesn't bother to
store.
All of this doesn't really matter anyways, since zip files can't be
used for base.tgz. Try the following test:
tar zcf /tmp/dev.tgz /dev
zip -r /tmp/dev.zip /dev
You'll note that tar can store devices, while zip fills up ram and (I
assume) eventually dies while trying to read from the devices.
The only real alternative to tar is cpio, but I haven't heard any
reasons why we shouldn't use tar. We need something that preserves
ownership, modification times, and permissions (including setuid and
sticky bits), and can store hard links, soft links and devices.
Preferably something that can correctly store files with holes in
them.
Steve
dunham@cps.msu.edu
Reply to: