Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
How does NTFS compression affect performance?

In theory, on a reasonably fast PC, the processor is mostly idle during hard drive access.

A compressed file takes up less physical space, so the hard drive (being the slowest part in the system) has to read less physical data.

One could argue that the small additional amount of work for the processor to uncompress the data on the fly will not result in slowdown of the read operation, so hence my question:

If I activate drive compression on a Windows machine, can I positively affect data throughput at the expense of a somewhat higher CPU usage?

share|improve this question

marked as duplicate by bwDraco, Simon Sheehan, Synetech, 8088, HackToHell Dec 23 '12 at 9:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

good question, the answer is that it depends! Depends on the data being compressed mostly, if its highly compressible then compressing may speed things up, "may" because there are other factores like is this data transactional etc.. – user33788 Jun 25 '10 at 16:53
I'm seeing interesting things ( for SSDs, an actual test for this would be awesome, I hope that I can find one... – Tom Wijsman Apr 24 '12 at 7:57
up vote 3 down vote accepted

Some discussion on the subject here

and here

too many variables for a direct answer.

share|improve this answer
Well, obviously the topic is moot. I was hoping for somebody who had actually measured it instead of theorizing about it, but then again I acknowledge that this is something where you can't make absolute statements. – Tomalak Jul 2 '10 at 17:11
@Tomalak: Actually, the above topics hold for a HDD (where the seek time is usually the largest), this does not hold for a SSD thus in that case it might be that it is a good thing to do on a SSD. If it is so, it would be great news because of the smaller sizes of a SSD. – Tom Wijsman Apr 24 '12 at 7:47

One would think that the processor overhead would be less than the drive access overhead and that compressed partitions would be faster. However, my experience suggests that it's almost always slower compressed...

share|improve this answer
But, what about SSDs? – Tom Wijsman Apr 24 '12 at 7:48

Since the difference in performance is not even notable I'd say there really isn't a difference but if you need the extra space then definitely go for it!

share|improve this answer

It depends heavily on what it costs by means of time to retrieve two disk sectors vs retrieving one sector and decompressing into two data sectors.

On a HDD, the biggest delay is related to disk revolution, thus defragmenting disk (or single file) will speed sequential read greatly.

For SSD, there is no seek delay, so defragmenting has a smaller effect (but still make pointers to file parts more compact in MFT, thus needing one extra read for fragment vs per whole file).

Example: I run OpenBSD off the CF card and kernel is 20 MB, which reads in 10 seconds. I compress it and it becomes like 6 MB, and reads in 3 seconds, one more second for decompression. In this embedded case, I save 5 seoconds off the boot sequence, so the read-only files can be compressed for good effect. (for example, a PXE bootable installer would be a good candidate).

A bigger problem turns up when you compress system databases like Windows Update or SQL Server, where big parts of file gets recompressed (that is, read, decompress, modify, recompress, and write) leading to ugly speed and enormous fragmentation.

At the price of modern disks, I'd suggest to buy quicker disk for speed locally, and limit compression to strictly read-only scenarios like netboot or install DVDs.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged .