Path: utzoo!mnetor!uunet!ncc!alberta!edson!tic!dragos!work
From: work@dragos.UUCP (Dragos Ruiu)
Newsgroups: comp.dcom.modems
Subject: Re: hayes 9600 vs. trailblazer
Message-ID: <404@dragos.UUCP>
Date: 17 Apr 88 20:19:55 GMT
References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <15617@onfcanim.UUCP>
Organization: UNIX Device, Canada
Lines: 28
Summary: Use 12 bit compress to save cpu cycles...

In article <15617@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes:
> 
> The UNIX compress program is pretty efficient about its data handling.
> It doesn't perform many instructions for each byte of input data.
> Uucico is somewhat expensive - it builds a packet header and computes
> a CRC for every 64 bytes of data.
[deletion]
> Note that for the unfortunate people with Intel-architecture machines,
> compress uses a kludge that slows down array addressing considerably,
> making compress as a whole much more expensive.  For these people,
> compression in the host may not be worthwhile.

  To achieve good compression on 'small' :-( architectures like the 286
  build a special version of compress that only uses 12 bit compression
  and use that for news. With a bit of twiddling you can even manage a 12
  bit compressor that works in the small memory model. My experience is that
  the drop from 16 bit LZW to 12 decreases compression ~10-15% but that the
  cpu load it removes is significant (orders of magnitude in performance
  differential). You could manage 14 bit decompression and still stay within
  the small memory model for performance.

  You might also take a look at the 'stripped' down 16-bit decompressor-only
  recently posted to one of the sources groups. But this is getting somewhat
  far afield of modems...

-- 
Dragos Ruiu   ruiu@dragos.UUCP
        ...alberta!dragos!ruiu   "cat ansi.c | grep -v noalias >proper.c"