[lenz]

Wow!!! this made a HUGE difference on my ibook 2001. I saved about 60 Megs of memory and things are MUCH speedier now(since memory bandwidth is a huge bottle neck in the ibook). This is great. OS X just keeps getting better!

[- - e r i k - -]

Well, it works now. Showing Cs in the Quartz Debug application. I can't tell a difference in performance though. It's certainly not slower. Swithing applications is now instantaneous. But I can't remember this being a problem before the patch either

Anyway OS X 10.1 is speedy as a cheetah on speed for me on my 400 G4 with 960 MB RAM...

Bo!

[Immortal K-Mart Employee]

Ok i appled the patch to one of my computers. I don't know if I did it right though. Is there any way to tell if it was activated?

[n1ce]

Ok, I just tried this on my iBook and the performance gain seems VERY impressive - window resizing, menu's, app launch all seem faster.

[moki]

Originally posted by Immortal K-Mart Employee:
<STRONG>Ok i appled the patch to one of my computers. I don't know if I did it right though. Is there any way to tell if it was activated?</STRONG>

The second post in this thread indicates how to "check for it" using the QuartzDebug application

[Cowdog]

I pasted the text in.. (also thanks Rick for the very cool root, textedit and theme tip).. and want to see if its working, so I opened quartz debug, though it's from the 10.0.4 tools, not 10.1..

{snip}

[edit: doh, I'm an idiot, never read the log out/re login part, nm I see Cs now, thanks]

[ 10-11-2001: Message edited by: Cowdog ]

[absmiths]

Where do you see pagein's and pageout's?

[3.1416]

Originally posted by absmiths:
<STRONG>Where do you see pagein's and pageout's?</STRONG>

Run "vm_stat" from Terminal. Ideally, pageouts should be 0.

[malvolio]

Okay, applied that hack, and got the C's in Quartz Debug. But since I just did it, it's too early to tell if there's any perceptible difference.
I'm gonna be checking Top pretty damn often for a while.

[selkirk]

Well, like many things, this optimization may involve some tradeoffs.

Since I started using the compression, I've noticed that sometimes the finder can take 30-40 seconds to open a new window. This has happened to me 3-4 times already and I haven't observed all of the details yet. In each case, I did not have any finder windows previously open and I hadn't used the finder in a long time. I am not ready to say that this delay is related to the buffer compression, but I was curious if anyone else noticed something like this?

I have definitely noticed an improvement in memory usage, but I am not sure that I have noticed a speed improvement. I'm going to give it a few days and then revert back to see if I notice a difference.

[moki]

Originally posted by selkirk:
<STRONG>Since I started using the compression, I've noticed that sometimes the finder can take 30-40 seconds to open a new window. This has happened to me 3-4 times already and I haven't observed all of the details yet. In each case, I did not have any finder windows previously open and I hadn't used the finder in a long time. I am not ready to say that this delay is related to the buffer compression, but I was curious if anyone else noticed something like this?</STRONG>

I've never seen that, and can say with some certainty that whatever the problem is, it has nothing to do with the buffer compression.

[dextrome]

I've seen absolutely no difference in performance. A couple of questions though: What is the delay before a window's buffer is compressed? What constitutes an update? For example say I'm browsing a web page with static data that's stayed the same for the past five minutes, but I scroll up and down on it... Will the window buffer for this window be compressed?

[ErsatzTom]

Originally posted by selkirk:
<STRONG>Since I started using the compression, I've noticed that sometimes the finder can take 30-40 seconds to open a new window. This has happened to me 3-4 times already and I haven't observed all of the details yet. In each case, I did not have any finder windows previously open and I hadn't used the finder in a long time. I am not ready to say that this delay is related to the buffer compression, but I was curious if anyone else noticed something like this?
</STRONG>

Perhaps your disk has spun down? You could try going into the energy saver control panel and set "put hard disk to sleep" time to never and see if it still occurs.

tom

[moki]

Originally posted by dextrome:
<STRONG>I've seen absolutely no difference in performance. A couple of questions though: What is the delay before a window's buffer is compressed? What constitutes an update? For example say I'm browsing a web page with static data that's stayed the same for the past five minutes, but I scroll up and down on it... Will the window buffer for this window be compressed?</STRONG>

If the contents of a window haven't changed in 5 seconds, the window server will attempt to compress the contents.

Scrolling a window will be considered an update, so the window won't be compressed. Remember, this applies purely to the on-screen window buffer.

[selkirk]

Originally posted by ErsatzTom:
<STRONG>

Perhaps your disk has spun down? You could try going into the energy saver control panel and set "put hard disk to sleep" time to never and see if it still occurs.

tom</STRONG>

Its not the disk spinning up.

[bowwowman]

It worked for me, sped up all window activity and app opening too.


B&W G3/450/1GB/vm swapfile on dedicated 5GB partition

Keep up the good work guys

[mpaque]

Originally posted by Zarafa:
<STRONG>

If I remember correctly, even back in the days of 25- and 33-MHz processors, NEXTSTEP did on-the-fly compression of memory pages written out to the primary swapfile. Not a strictly comparable process, of course, but it's a good way of demonstrating that even then real-time compression/decompression of certain data was deemed to be a good idea.

So I really think you're mistakem.</STRONG>

You do remember correctly.

In addition, as of OPENSTEP 4.0, the NeXT window system compressed window backing stores when they hadn't been written for several seconds, and refreshed the display directly from the compressed data.

The mechanism sounds remarkably similar to what's going in in the Mac OS X window manager process. What an amazing coincidence...

Mike Paquette

[jock]

Andrew your a bloody hero mate
worked for me on my Ti book and sawtooth
cheers

[fisheater]

Andrew-

Thanks! Maybe this way you will make up for some of the time you took away with Apeiron/Maelstorm.

-jon

[ 10-14-2001: Message edited by: fisheater ]

[gorgonzola]

Mike Paquette

I seem to remember that name from somewhere -- didn't you design some major components of Aqua or something?

If not, just ignore me.

[Elifarley]

I've tried a dozen times changing the file com.apple.windowserver.plist, but after I re-login, my changes are no longer there.

Does anyone have a clue as to why the changes don't persist?

[Bouba]

It happened to me until I noticed that I was pasting the settings at the wrong place...

[Brazuca]

worked for me...im very happy

[Hash]

Thank you, Mr. Welch for this hint.

I tried using MS Word in OS9.2.1 to edit the preferences. After restart in OSX it gave a really sharp performance in Finder, incredible speed-up. Usually, (i am not heavy user), i turn off my mac after using it. however, after restrart the shaprness disappeared and Finder speed same as it was before. I have the same question as the person above:

I've tried a dozen times changing the file com.apple.windowserver.plist, but after I re-login, my changes are no longer there.

Does anyone have a clue as to why the changes don't persist?

[ 10-15-2001: Message edited by: Hash ]

[Doug Barth]

I'm noticing some very strange behavior using this hack on a B&W G3.

My window dragging and dock menus seem slower depending on a very odd variable... the size of my desktop picture.

What I've found is that if I use a desktop picture that is the exact size as my preferred resolution, my window dragging and dock menus are slower. I also noticed that under this situation, the desktop picture is compressed.

Now, if I instead use a desktop picture that is stretched to fit on my screen, I notice no slow down, and the desktop picture is not compressed. Odd, huh?

This is all occurring on a standard B&W G3. The only changes are an overclocked processor, 512 MB of memory, and a 30 GB hard drive which currently has a clean install of 10.1.

Am I missing something else that would cause this?

[Geobunny]

A bizarre one I've noticed is that when I'm running the screen saver, the password dialog takes ages to show up (between 5 and 10secs). Not sure if this is because of the window buffering or not 'cos I didn't use the password feature before applying the hack. Anyone else got this happening to them?

[Edit: Fixed a typo - sorry I can't edit the post which quoted mine!]

[ 10-16-2001: Message edited by: Geobunny ]

[Gee4orce]

Originally posted by Geobunny:
<STRONG>A bizarre one I've noticed is that when I'm running the screen saver, the password dialog takes ages to show up (between 5 and 10secs). Not sure if this is because of the window buggering or not 'cos I didn't use the password feature before applying the hack. Anyone else got this happening to them?</STRONG>

That's nothing - I get delays of a minute or more if there's no DNS available on the network.

[eggonrye]

hey worked for me -everything much snappier MT 466 cpu 700+RAM. Don't knock it till you try it maybe

[Geobunny]

Originally posted by Gee4orce:
<STRONG>

That's nothing - I get delays of a minute or more if there's no DNS available on the network.</STRONG>

Maybe that's the problem then. The DNS servers on my uni network are shonky as hell!

[[email protected]]

if you run the console in the background, it will tell you when the dns times out...

or you can tail -f /var/log/system.log

i was also gonna say i couldn't get the hack to work, but i just now noticed the first &lt;dict&gt; statement is higher than i am. (i put it in the display sets dict area (DUH, i'm a moron)).

[moki]

Originally posted by eggonrye:
<STRONG>hey worked for me -everything much snappier MT 466 cpu 700+RAM. Don't knock it till you try it maybe
</STRONG>

For what it's worth, I'm fairly certain that the next OS update will include this enabled by default. I have no inside information, but I think it's a good bet...

[WTWolfe]

Applied the Buffer Compression "Hint" on the iBook, works like a charm! Thanks Andrew! You the MAN!!!!!

[ 10-17-2001: Message edited by: WTWolfe ]

[smigol]

I tried the fix on my 8500/G3 500 with 480 MB RAM....

Prior to the fix, even with all this RAM, I only had about 30 MB free...

Now, I have 309MB free.

Plus, the machine is much quieter since it doesn't have to page anywhere near as much!

[someguyupnorth]

I decided to test this hack by checking my memory PRE and POST "hack" with the top command. Unfortunately for the guy posting this, his hack actually ate up 100MB of memory. I've got an iMac DV 400 w/512mb of ram. I had 174MB free with the hack on and 241 with it off. Hope this helps others who are on the fence about this.

-someguyupnorth

[moki]

Originally posted by someguyupnorth:
<STRONG>I decided to test this hack by checking my memory PRE and POST "hack" with the top command. Unfortunately for the guy posting this, his hack actually ate up 100MB of memory. I've got an iMac DV 400 w/512mb of ram. I had 174MB free with the hack on and 241 with it off. Hope this helps others who are on the fence about this.</STRONG>

um... "no". I don't know what else to say to you, other than your measurement wasn't correct (something else must have changed as well).

[Elifarley]

Originally posted by someguyupnorth:
<STRONG>I decided to test this hack by checking my memory PRE and POST "hack" with the top command. Unfortunately for the guy posting this, his hack actually ate up 100MB of memory. I've got an iMac DV 400 w/512mb of ram. I had 174MB free with the hack on and 241 with it off. Hope this helps others who are on the fence about this.

-someguyupnorth</STRONG>

I think the "free" reading from top should always be close to very few MB (4 MB or less), no matter how many gigabytes of RAM you may have, because any unused memory (unused by applications, kernel code, etc) should be used as a cache.

Let's suppose you do a

<STRONG>
find / -name "*a*"
</STRONG>

Your HD will thrash a lot the first time you issue this command, but by the second time you do, your HD may even not be touched at all, and the search will be much faster, provided you have lots of RAM.

As soon as applications need more active memory, the system will discard cache data to provide it, so you will end up with almost no free memory, as reported by top.

[oranjdisc]

Well...I must be a total newbie when it comes to the Terminal, for I can't get past the first part.

When I type in the "sudo pico /library/preferences/com.apple.windowserver.plist"...

...I get....

"sudo: pico: command not found"

????

[malvolio]

Did you include the BSD portion when you installed OS X? Without it, some of the most common and useful Terminal commands will not work.

[oranjdisc]

Originally posted by malvolio:
<STRONG>Did you include the BSD portion when you installed OS X? Without it, some of the most common and useful Terminal commands will not work.
</STRONG>

AHA! That was it. I left out that part of the installation 'cause this was just for my iBook, and I didn't think I'd need the BSD option.

So I installed it...and got window buffering rockin'!!

[Jaharmi]

I actually had a problem where I had installed the BSD subsystem (the default) for 10.0 (a fresh install), and upgraded to 10.1. Afterwords, I was missing a bunch of commands -- for example, ifconfig, chown and quite a few others were missing. (Others, like chmod and ls, were there. So it was highly confusing to me.) This led to problems where I could not change ownership of files/directories, could not properly create new users (their home directories were set to "root" ownership), and my Terminal.app prefs were all messed up.

Eventually, I copied all of the UNIX commands from another Mac OS X machine with cpio, and got all that stuff back with the right permissions. Needed some help from a UNIX-savvy student, but it worked, and saved me having to reinstall anything (at least through the installer app).

[boots]

I'm not a computer science person, so if this is a stupid question, please forgive me....

What if you routinely run CPU intensive apps (especially in the background)? Does the cycling price then become significant? For example, I have a g4 400 MHz running with approx 400 MB RAM. I usually have a couple of gaussian calculations (ab initio molecular modeling) running in the background. These chew up the CPU, but not so much the memory. The entire system is certainly much slower when these calculations are running. I added 1GB of ram, and this helped significantly in the time it takes to switch processes (windows), but I don't think the intrinsic CPU performance could be changed. The question, then, is would this compression work as well under CPU intensive conditions as simply adding more RAM? One could imagine that with programs like Photoshop running, this preference "trick" wouldn't be particularlry effective, and could actually hurt the performance of the apps themselves.

(This probably doesn't apply to 90%+ of users, but it certainly speaks to some users.)

[moki]

Originally posted by boots:
<STRONG>I'm not a computer science person, so if this is a stupid question, please forgive me....

What if you routinely run CPU intensive apps (especially in the background)? Does the cycling price then become significant? For example,</STRONG>

Nope. Here's the deal. Modern processors are extremely fast; accessing memory is comparitively slow. This is the reason for level 2 and level 3 caches in computer systems.

Let's say I need to copy a chunk of memory (such as a window buffer). I read in a piece of the data, then I write it out to its new location. The thing is, reading and writing from memory is slow, and the buffers are so large that they will be larger than any data cache (and even if they aren't, it'll slam the data cache, knocking out any other useful data that may have been in there).

So what happens is the processor asks to read a piece of data, then it just sits there waiting, doing nothing while the data is transferred. Using this form of buffer compression, the processor can uses these free cycles to decompress the data while it is waiting for other data to transfer. Even if this takes up slightly more time per piece of data transferred (which it usually doesn't), so much less data needs to be transferred that the operation is significantly quicker.

[Immortal K-Mart Employee]

So was this feature turned on by Apple with that security update?
Is it turned on in the 10.1.1 beta's?

[typoon]

I didn't see any difference with this hack either til I logged out and logged back in . Now I do see improvement

[moki]

Originally posted by typoon:
<STRONG>I didn't see any difference with this hack either til I logged out and logged back in . Now I do see improvement</STRONG>

That makes sense, since you have to log out and back in again to activate it.

[moki]

Originally posted by Immortal K-Mart Employee:
<STRONG>So was this feature turned on by Apple with that security update?
Is it turned on in the 10.1.1 beta's?</STRONG>

No, the feature wasn't turned on by the security update. As for the 10.1.1 betas, I don't have access to them, and even if I did, I couldn't say anything about 'em. Sorry.

[Todd Madson]

What about for guys like me with stupid amounts of ram (currently at
1216 megabytes)? I'll give it a try to see if it improves my system
performance, but things are already pretty snappy (G4/400).

Thanks for the tip - sounds very intriguing to say the least.

[Todd Madson]

Interesting: I opened every app on the system at the same time, then exited them and got this:

Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 200521.
Pages active: 21929.
Pages inactive: 62178.
Pages wired down: 26668.
"Translation faults": 881330.
Pages copy-on-write: 37895.
Pages zero filled: 598640.
Pages reactivated: 0.
Pageins: 12592.
Pageouts: 0.
Object cache: 9304 hits of 39078 lookups (23% hit rate)

0. Wow.

[andyinindy]

OK, so I was curious enough about this that I decided to give it a try. What I didn't consider was the fact that I am running 10.0.4 and not 10.1. After I hacked the preferences file and logged out and back in again, things were acting really screwy. I would open an app, it would bounce in the dock for a while, and then stop bouncing, as if open. But, I couldn't see any windows for the app, and force quit dialog showed no open apps. Hmm.

So, I logged out and back in AGAIN. Things are operating correctly in that apps will now open without problems. However, in the Quartz Debug app, there are no "C"'s next to my sizes in the kb column. Hmm, so I figured that the preferences had defaulted to the original setting. Opened com.apple(etc) file and the new values were still there... the hack had stuck.

So why aren't my windows being compressed? Maybe it was a bad idea to do this under 10.0.4......... Any suggestions? I have checked and triple checked the text of the hack... all is as it should be. And yes, it's in the right location (just below the first &lt;dict&gt; ) Does 10.0.4 handle window compression differently than 10.1? Am I royally screwed??

[moki]

Originally posted by andyinindy:
<STRONG>So why aren't my windows being compressed? Maybe it was a bad idea to do this under 10.0.4......... Any suggestions? I have checked and triple checked the text of the hack... all is as it should be. And yes, it's in the right location (just below the first &lt;dict&gt; ) Does 10.0.4 handle window compression differently than 10.1? Am I royally screwed?? </STRONG>

This hack only works with OS X 10.1 or later. Upgrade to 10.1, there's no reason not to.