🚀 go-pugleaf

In article <1b4us9INN7nv@stephen.cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:
>In article <1992Oct8.064554.3163@cubetech.com> andrew@cubetech.com writes:
>>In article <1atfn1INNi4p@stephen.cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:
>>>andrew@cubetech.com (Andrew Loewenstern) writes:
>>>>If you have a Turbo, try turning on the "swaptimizer" (see the swaptab
>>>>man page).  The swaptimizer compresses pages before they go out to
>>>>disk to reduce disk IO.
>>>
>>>Does anyone know the compression algorithm used here?
>>
>>Probably LZW.  Maybe even Huffman, but I would bet on LZW.  The trick
>>is to find something that will do a reasonable job as quickly as
>>possible.
>
>I wouldn't leave run-length encoding out of that list.  For the right
>kind of data, RLE has a good compression/CPU ratio.  The thing is,
>what kind of data is normally paged out?  Also, what is the granularity,
>single 8K pages or larger multiples?  If you're doing LZW, would you maintain
>a dictionary for each single page, or for the whole swapfile, or something
>in between?
>
>My intuition says that they're using RLE.  I assume that much of the
>paging on low memory and especially colour machines is backing store
>for window bitmaps.  Take a look at the windows
>on your screen.  On my desktop, I see a high percentage of contiguous
>colours (grey and white).  RLE eats this stuff for breakfast.

Hmmmm, maybe so.  The release notes say it works great for standalone
machines, but not so great for things like compile servers...

>Maybe NeXT licensed Stacker for their swapfile :~)

hehe...  probably not.....


andrew
-- 
andrew@cubetech.com     | "We shall not cease from exploration
Andrew Loewenstern      |  And the end of our exploring
Cube Technologies, Inc. |  Will be to arrive where we started
                        |  And know the place for the first time." -T.S. Eliot