Is Apple's Memory Compression Better in Theory than in Practice?

As I continue to struggle with Mavericks' substandard performance (which involves responsiveness as well as robustness), I have been fascinated with an article by Robin Harris that showed up on ZDNet on Monday. Harris' opening paragraphs give a good summary of his story:

For most of Mac history using the standard memory configuration meant a world of hurt. The machine would boot and work well - usually - with one app at a time, but open a few Safari tabs, Mail, a media player and a word processor and switching apps gets s-l-o-w.

In a virtual memory OS - all consumer/server OSs today - physical memory is extended by using mass storage - disk or SSD - to store inactive or little used memory pages. That frees physical memory - DRAM - for use by active programs.

The downside is that moving those pages back to DRAM takes a disk several hundred thousand times longer than accessing them in DRAM. An SSD takes thousands of times as long.

Compressed memory
A new feature of Mac OS 10.9 - Mavericks - compressed memory, increases the effective size of DRAM through inline data compression. This isn't a new idea: over 20 years ago the HP Omnibook 300 used inline compression to double the effective size of its 10MB compact flash card.

What is new is that with multiple cores running an optimized compression algorithm the system can compress/decompress data much faster than swapping to disk or SSD. This saves time and energy, since the system isn't idling waiting for memory page swaps - important for notebooks.

And there's nothing to configure: it works automatically in the background. All you see is a more stable Mac with more memory.

Now I rarely try to keep as many independent processes and Safari tabs going as Harris does. However, I tend to have several applications at my disposal; and switching them has never been a problem. Under Mavericks, on the other hand, anything involving memory management, even something as simple as saving a file, consumes so much time that it is wise to schedule it in conjunction with a bathroom break.

The first thing I did by way of reaction to this pathetic state of affairs was to compare Harris' configuration with my own. To my surprise, there were no great differences. The next thing I did was to follow his advice and check out the Memory pane of Activity Monitor. This was where the shock hit. There is now a glut of new processes with the prefix comm.apple. In the grand scheme of things, these are not that large; but com.apple.IconServicesAgent consumes 4.4 MB, leading me to wonder why "icon services" need to be so complex.

Now I do not want to accuse Harris of making false claims. I am sure that everything he says works for him. However, on the basis of my experience, it would appear that what works for him as a "power user" does not necessarily work "for the rest of us" (to invoke the words of the old Apple selling pitch). To invoke a less polite epithet, I would suggest that, somewhere out there in the world of ordinary Mac users, there is a pooch whose rear end is feeling very sore right now!