Xref: utzoo comp.unix.microport:1019 comp.unix.xenix:2682
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!oodis01!uplherc!sp7040!obie!wes
From: wes@obie.UUCP (Barnacle Wes)
Newsgroups: comp.unix.microport,comp.unix.xenix
Subject: Re: speeding up compress on 286
Summary: performance problems?  Hah!
Message-ID: <100@obie.UUCP>
Date: 14 Jul 88 05:52:40 GMT
References: <347@bdt.UUCP>
Organization: the Well of Souls
Lines: 24

In article <347@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes:
> Has anyone looked into speeding up compress on the 286?  Under
> Microport System V/AT compress runs really slooow.

Mine, too.  That's why I stopped running compress - I just get
everything batched but uncompressed.  It's slower, but fast enough, and
works well.

> ................   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.

It might be, but I upgraded my system from 1 meg to 3, and it really
didn't help much.  The 16-bit compress is right near the limit for
process size on V/AT, and it seems to swap a lot regardless of how much
memory you have.  You might want to look at the 13-bit compress, I
understand it is much faster, especially on brain-dead architectures
like the '286.
-- 
                     {hpda, uwmcsd1}!sp7040!obie!wes
           "Happiness lies in being priviledged to work hard for
           long hours in doing whatever you think is worth doing."
                         -- Robert A. Heinlein --