This 24 GB Mac is holding 17 GB of data in 6.6 GB of RAM
The memory compressor is doing 2.58 to 1 on live data right now, and it is the reason Apple can ship machines with memory configurations that look too small on paper. Here is the ratio, measured.
At the moment I took this reading, this MacBook Pro had 876 MB of unused RAM, 2.58 GB of swap in use, and a memory compressor holding 17.05 GiB of logical data inside 6.61 GiB of physical memory. That last figure is the one worth pausing on. A single mechanism was recovering 10.44 GiB, which is 43.5 percent of everything the machine has.
This is the actual answer to why Apple’s memory configurations look implausible on a spec sheet and mostly do not feel implausible in use.
The two numbers that matter
vm_stat reports around twenty counters and almost every explanation of it focuses on the wrong ones. These are the two that produce the ratio:
vm_stat | grep -E "Pages (stored in|occupied by) compressor"Pages stored in compressor: 1117741.
Pages occupied by compressor: 433288.The first is how many pages of data the compressor is responsible for. The second is how much physical memory it is using to hold them. On Apple Silicon a page is 16,384 bytes rather than the 4,096 that most documentation written for Intel assumes, so:
stored: 1,117,741 × 16,384 = 18,313,068,544 bytes = 17.05 GiB
occupied: 433,288 × 16,384 = 7,098,990,592 bytes = 6.61 GiB
ratio: 2.58 : 1
recovered: 18,313,068,544 - 7,098,990,592 = 11,214,077,952 = 10.44 GiBtop agrees, from a completely separate code path:
PhysMem: 22G used (2956M wired, 6770M compressor), 876M unused.6770 MB is 6.61 GiB. Two tools, same figure.
What 43.5 percent recovery actually buys
Without the compressor, holding that same working set would require 17.05 GiB of real pages instead of 6.61 GiB. On a 24 GiB machine already carrying 2.96 GiB of wired memory that the kernel will not release, the difference is between a system that is comfortable and one that is swapping continuously.
That framing is usually where these articles stop, with compression cast as the hero. The measurement does not entirely support that reading.
Compression did not prevent swapping
At the same moment, on the same machine:
sysctl vm.swapusagevm.swapusage: total = 3072.00M used = 2639.25M free = 432.75M (encrypted)2.58 GB of swap in use, with 86 percent of the current swap file occupied. The compressor was recovering 10.44 GiB and the system was still writing to disk.
These are not sequential stages where compression happens first and swap is the emergency fallback. They run together. Pages get compressed; compressed pages that stay cold get written out to swap anyway. The lifetime counters make the scale of the traffic clear:
| Counter | Value |
|---|---|
| Compressions | 588,645,523 |
| Decompressions | 491,673,004 |
| Swapouts | 7,652,945 |
| Swapins | 5,032,125 |
588 million compressions against 7.6 million swapouts. Compression is the routine path and swap is the exception, but the exception is being taken millions of times.
What it costs
Compression is not free memory, it is memory traded for CPU. Every access to a compressed page requires decompressing it first, on the critical path, while the requesting thread waits. 491 million decompressions have happened on this machine.
Apple Silicon absorbs this well because the compressor runs on cores with very high memory bandwidth, and because the algorithm is tuned for speed over ratio. That is precisely why the ratio is 2.58 and not the 4 or 5 to 1 a slower algorithm could reach. The design target is latency, not density.
The cost shows up as a soft, hard-to-attribute slowdown rather than as an obvious stall. It is the reason a machine can feel fine on a benchmark and slightly sticky in daily use with thirty tabs open.
Why your ratio will differ
2.58 to 1 is what this machine achieved with this working set. It is not a constant, and quoting it as one would be a mistake.
Compression ratio depends entirely on what is in memory. Source code, text, JavaScript heaps, and the large sparse structures that interpreted languages allocate all compress well. Video frames, decoded images, encrypted buffers and already-compressed archives do not compress at all, because they have no redundancy left to exploit. A machine editing video will show a materially worse ratio than one running a browser and an editor, which is what this one was doing.
The two samples I took minutes apart already differed: free pages moved from 9,128 to 52,869 as the system rebalanced. These are point-in-time readings of a live system, not steady-state values.
Measuring your own
# The ratio
vm_stat | grep -E "Pages (stored in|occupied by) compressor"
# Confirm against a second tool
top -l 1 -s 0 | grep PhysMem
# And whether swap is running alongside it
sysctl vm.swapusageMultiply both page counts by 16,384 and divide one by the other. If your ratio is well above 2.58, your working set is mostly text and code. If it is close to 1, you are holding data that cannot be compressed and additional RAM would help you more than it would help most people.
The useful conclusion is not that compression makes memory free. It is that the number on Apple’s spec sheet and the amount of data your machine is actually holding are different quantities, and the gap between them is measurable in two commands.
Watching the ratio change
The figure is not static and watching it move is more informative than any single reading.
watch -n 5 'vm_stat | grep -E "Pages (stored in|occupied by) compressor"'watch is not present on macOS by default, so the portable version:
while sleep 5; do
vm_stat | awk '
/Pages stored in compressor/ {gsub(/[^0-9]/,""); s=$0}
/Pages occupied by compressor/{gsub(/[^0-9]/,""); o=$0}
END {printf "stored %.2f GiB occupied %.2f GiB ratio %.2f\n",
s*16384/1073741824, o*16384/1073741824, o>0 ? s/o : 0}'
doneOpen a large number of browser tabs and the stored figure climbs while occupied climbs more slowly, so the ratio improves: web content is text and compresses well. Open a video editor and the ratio falls, because decoded frames have no redundancy left to exploit.
That responsiveness is the point. The compressor is not applying a fixed transformation, it is exploiting whatever redundancy your particular working set happens to contain, and the amount of help you get from it depends entirely on what you run.
What this means for a purchase decision
The honest version of the memory-configuration argument runs like this.
Compression means a machine with less RAM stays comfortable longer than the raw numbers suggest, because a large fraction of a typical working set is compressible. On this machine that fraction was recovering 43.5 percent of total memory.
It does not mean memory is free. The 2.58 GB of swap in use at the same moment is the evidence: compression was working hard and the system was still writing to disk. Compression delays the point at which more RAM would help; it does not remove it.
And the benefit is workload-dependent in a way that a spec sheet cannot express. If your work is text, code and browsing, the effective capacity of a given configuration is substantially larger than the label. If your work is video, images, or anything already compressed, it is close to the label, and the gap between two configurations matters more than a general recommendation would suggest.
Measuring your own ratio, on your own workload, answers this better than any review can.
The one command worth remembering
vm_stat | awk '
/Pages stored in compressor/ {gsub(/[^0-9]/,""); s=$0}
/Pages occupied by compressor/{gsub(/[^0-9]/,""); o=$0}
END {printf "holding %.2f GiB in %.2f GiB (%.2fx)\n",
s*16384/1073741824, o*16384/1073741824, o>0 ? s/o : 0}'One line, no privileges, and it answers the question this whole article is about. Run it on your own machine and the number you get describes your working set rather than mine.
Takeaways
- The compressor was holding 17.05 GiB of logical data in 6.61 GiB of physical RAM, a ratio of 2.58 to 1.
- That single mechanism recovered 10.44 GiB, which is 43.5 percent of the machine's total memory.
- Compression did not eliminate swap: 2.58 GB of swap was in use at the same moment, so both mechanisms run together rather than in sequence.
- Lifetime counters show 588 million compressions against 491 million decompressions, so this is continuous background work, not an emergency measure.
Questions
- Does memory compression mean I can buy less RAM?
- It means the shortfall hurts later than it otherwise would, not that it never hurts. Compression costs CPU time on every access to compressed data, and this machine was still using 2.58 GB of swap while compressing, so the mechanism was already running alongside its fallback.
- Is a 2.58 to 1 ratio typical?
- It depends entirely on what is in memory. Text, code and interpreted runtimes compress well; already-compressed data such as video, images and encrypted buffers does not. A machine running different software will produce a different ratio, which is why measuring your own is more useful than quoting this one.
- Should I worry that only 876 MB was unused?
- No. Unused RAM is wasted RAM, and macOS deliberately keeps very little of it. The figure that indicates pressure is swap activity and the memory pressure percentage, not the unused number.
Sources
What we read. Distinct from what we measured, which is in the article itself.