🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.macintosh
Article #10

OS X 10.1 - Speedup Tip

#10
From: Jackie Chan Fan
Date: Sat, 13 Oct 2001 11:51
100 lines
5824 bytes
Here's a great tip by Andrew Welch, of Ambrosia Software : 

The window server has a cool feature in OS X 10.1 that isn't enabled by 
default (though it will be in an upcoming update, as I understand it): window 
buffer compression. 

A little background. Under OS X, the contents of each window are saved in a 
buffer, so that they can be updated instantly, and also so that the cool 
transparency effects in Aqua are possible. This is a good thing, to have a 
fully buffered window manager -- however, it uses a lot of memory. 

In 32 bit mode ("Millions" in System Preferences), a window that is 800 
pixels wide by 600 pixels high uses up 1.9mb of RAM. When you consider that 
there are usually over 100 windows open when you're using OS X (not all 
windows are visible), you start to realize that this can start to add up in 
terms of RAM usage. 

The more windows you open, the more RAM they use up, the more that virtual 
memory will have to page in and out while you use your applications to do 
work. This can cause slow-downs as the disk grinds to do the virtual memory 
paging. 

So what Apple did was they implemented a compression mechanism into the 
window server. When a window's contents haven't changed for a given period of 
time, the window server compresses them, so they take up less memory. Since 
it uses a compression method that doesn't require the buffer to be fully 
decompressed to do compositing (dragging a window around, updating the 
screen, etc.), you won't notice a slowdown with this compression turned on. 

In fact, because less memory is being used up by the window buffers, more RAM 
will be available for your applications, with will mean less virtual memory 
paging, and may in fact result in speeding up your machine. Additionally, 
since less data needs to be read (it is compressed, after all!), things like 
updating windows may be faster as well. 

If you are a power user who has lots of windows open, you might consider 
giving this hack a shot. I'm using it, and getting compression ratios of 
about 8.5:1 (in other words, my window buffers are using 8x less RAM than 
they normally would). 

Now then, onto the hack! First, open up the Terminal application (found in 
/Applications/Utilities/) and type: 

sudo pico /Library/Preferences/com.apple.windowserver.plist 

(you'll need to enter your admin password in order to proceed) 

Move the cursor down below the first <dict> tag, and paste the following text 
in: 

<key>BackingCompression</key> 
<dict> 
<key>compressionScanTime</key> 
<real>5.000000000000000e+00</real> 
<key>minCompressableSize</key> 
<integer>8193</integer> 
<key>minCompressionRatio</key> 
<real>1.100000023841858e+00</real> 
</dict> 

Then hit Control-X to exit pico (hitting the Y key to save the changes before 
exiting when it asks you), then log out and back in again, and ta da! 
Compressed window buffers. Enjoy... 

If you want to verify that your window compression is working, install the OS 
X 10.1 developer tools, and run the QuartzDebug app 
(/Developer/Applications/), then click on the "Show window list" button. 

Windows that have compressed buffers will have a C next to the size of the 
window's buffer in the kByte column of the window list. 

Some people are a bit concerned that enabling this compression might slow 
things down; that's actually not true. It will actually be faster, for the 
two reasons I mentioned. First, less swapping (which will happen somewhat, 
regardless of how much RAM you have). 

Secondly, consider that most modern CPUs are memory bandwidth-bound. When you 
need to update a window with a 200K buffer, you have to read in 200K of data, 
then write out 200K of data. 

The vast majority of the time spent doing this copying involves the CPU just 
sitting and spinning waiting for data. If you use the compressed buffer, and 
a reasonable 10:1 compression ratio, you only need to read in 20K of data, 
running it by a simple algorithm, and write out 200K of data. 

Since your are 10x less memory bound, and since you're using CPU cycles that 
would have been wasted anyway, you are faster. This is the same principle 
behind RLE blitters, etc.

-- 

Regards

Roo


==============================================================
 Posted with Hogwasher. Mac first, Mac only:
     http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html 
==============================================================
Technical Details
Message-ID: <01HW.B7EE67B90004B8B7072002D0@news-server>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!news.maxwell.syr.edu!feed2.uncensored-news.com!propagator!feed2.newsfeeds.com!newsfeeds.com!news-in-austin.nuthinbutnews.com!intgwlon.nntp.telstra.net!news-server.bigpond.net.au!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1005d0,8dbb8ca1d1c2fcf9,start
X-Google-Attributes: gid1005d0,public
X-Google-Thread: 10f675,8dbb8ca1d1c2fcf9,start
X-Google-Attributes: gid10f675,public
X-Google-Thread: 10b5e3,8dbb8ca1d1c2fcf9,start
X-Google-Attributes: gid10b5e3,public
X-Google-ArrivalTime: 2001-10-13 04:51:16 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!news.maxwell.syr.edu!feed2.uncensored-news.com!propagator!feed2.newsfeeds.com!newsfeeds.com!news-in-austin.nuthinbutnews.com!intgwlon.nntp.telstra.net!news-server.bigpond.net.au!not-for-mail
From: Jackie Chan Fan <512teer@expireit.com>
MIME-Version: 1.0
User-Agent: Hogwasher/2.6.1 (Macintosh)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <01HW.B7EE67B90004B8B7072002D0@news-server>
Subject: OS X 10.1 - Speedup Tip
Newsgroups: comp.sys.macintosh,aus.computers.mac,aus.mac
Lines: 101
Date: Sat, 13 Oct 2001 11:51:13 GMT
NNTP-Posting-Host: 61.9.186.20
X-Complaints-To: news@bigpond.net.au
X-Trace: news-server.bigpond.net.au 1002973873 61.9.186.20 (Sat, 13 Oct 2001 21:51:13 EST)
NNTP-Posting-Date: Sat, 13 Oct 2001 21:51:13 EST
Organization: BigPond Internet Services (http://www.bigpond.net.au)