[net.unix-wizards] Compact/Uncompact

dpk@BRL-VGR.ARPA (07/05/84)

From:      Doug Kingston <dpk@BRL-VGR.ARPA>

	The programs compact and uncompact on Berkeley 4.2 are
horribly expensive to use.  They use around 6 times as much CPU
time as an equivalent program on the PDP11.  This is ridiculous.

File was 10500 chars (larger files are no better)

	11/70
		pack	1.7u	0.7s	0:03r	26% compaction
		unpack	0.9u	0.6s	0:02r
	VAX 780
		compact	7.9u	0.3	0:08r	27% compaction
		uncompact 5.9u	0.3s	0:06r

I also had a compacted file of 873000 chars that took 610 seconds
of CPU time to uncompact.  This is silly.  I profiled compact and
it looks like its ripe for improvement.  Has anyone attempted
to fix this?

					-Doug-

gwyn@BRL-VLD.ARPA (07/05/84)

From:      Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA>

Personally I use the System V pack & unpack/pcat.

mark@umcp-cs.UUCP (07/07/84)

Rather than improve compact/umcompact, better to just port pack/unpack.
That is what we did.  Pack/unpack run fine on vaxes.
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark

dan@idis.UUCP (07/10/84)

I get the impression from the manual page for compact/uncompact
that the programs might update internal encoding/decoding tables
after each byte is processed.  If this is the case, changing the
code to update the internal tables less often might improve
performance.  This change would also make the new compact/uncompact
incompatible with the old versions (possibly a serious problem
considering that one major use of compact/uncompact is to reduce
uucp xfer times for large files).

				Dan Strick
				[decvax|mcnc]!idis!dan

dgs@hpfclv.UUCP (dgs) (07/12/84)

Look in net.sources for utah-cs!thomas's listing of 'compress'
I haven't tried it but he claims that is is much faster and better
than either 'compact' of 'pack'.  

		Try it, you'll like it.
		
		Dan Schmidt
		(hpfcla!dgs)

ka@hou3c.UUCP (Kenneth Almquist) (07/13/84)

Even the System V pack/unpack can be improved.  The unpack code processes
one bit at a time; I got about a fourfold speed improvement by modifying
the code to pull off 8 bit chunks.  Before that I recoded the unpack routine
in PDP-11 assembly language which resulted in a comparable performance
improvement without modifying the unpacking algorithm.
				Kenneth Almquist