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