speeding up compress on 286

[David Hutchens]

>From article <347 at bdt.UUCP>, by david at bdt.UUCP (David Beckemeyer):
> 
> Has anyone looked into speeding up compress on the 286?  Under
> Microport System V/AT compress runs really slooow.  On a my 10MHz
> 286 with (only) 2MB RAM a 60K test file generally gives times of:
> 
> 	20.0u 1.0s
> 
> or there abouts.   I assume the slowness is mostly due to the hack
> to "simulate" larger than 64K arrays (which Xenix and Microport don't
> handle!).  My particular problem may be raleted to swapping, in which
> case the speeds might be better if I had more RAM.
> 
> Does anybody else suffer similar performance problems and if so, has
> anybody looked into speeding it up?
> -- 

I don't know about Microport, but I have found that a LOT of time
is spent doing long shifts on my Xenix system when I use a 16-bit
compress.  This is in part because the C compiler generates a call
to a routine to do long shifts.  What is worse, they coded the
routine so that it is space efficient, rather than time efficient (It
uses a total of 3 or 4 286 instructions looping through them as many
times as the number of bits you wish to shift: i.e. it shifts one
bit each time through the loop.)  I found that I could write my
own routine - using a grand total of 50 more bytes or so, and in doing
so I decreased the time required to do a 16-bit compress by about 30%!

I don't have the code in front of me but the basic idea was to use
the 16-bit shift instructions and OR together the appropriate results.
I suspect that for 1 and possibly 2 bit shifts the provided routine is
faster, but compress does a lot of shifts of 10 bits or more, and with
these, my routine wins by a BIG margin.

		David Hutchens
		hutch at hubcap.clemson.edu
		...!gatech!hubcap!hutch