Pros & Cons of compressing the Operating System [Moved from News]

I didn't turn up a thread for this tbh.

The tutorial on compressing binaries (is that the one?)
Compress or Uncompress Windows 10 with Compact OS

isn't the same as compressing the whole C drive via disc properties. I followed Shawns TUT a week or so back and gained the space detailed. Compressing the whole drive was totally different as this compresses all user files as well.

Maybe there is another thread I didn't pickup.

Mooly said:

I didn't turn up a thread for this tbh. The tutorial on compressing binaries (is that the one?)
...Maybe there is another thread I didn't pickup.

kado897 said:

Yes, that was the one I was thinking of and I agree it doesn't cover all aspects discussed here.

Well, now there is a thread on this topic. The Mods have now spun this discussion off into a thread of its own.

FWIW I have only once needed to compress the whole of an ntfs C: drive, and that was back in the days of XP so not directly relevant. General impression was that it was slower to open or close files/apps, but not significantly so.

This idea goes back many years to MS-DOS days when there were a few options to compress the drive ms even built it in to MS-DOS at one point. In those days we had a 20 meg hd the main gain came from reduced disk read as it read less from the drive and uncompressed In ram

Many thanks to @z3r010 for creating the new thread for this topic.

Having gone back to the uncompressed image this morning I can confirm there seems to be less CPU activity averaged out minute to minute and hour to hour. Battery life on a laptop is an obvious beneficiary of that.

Another 'con' to the compressed image that emerged in use was that a simple transfer of files to a USB flash drive was quite slow, I assume as all the files had to be decompressed first. This is something I do regularly in addition to disk backups. On a USB 2 drive the transfer rate for a few hundred .jpgs was only around 3.5mb/s It seemed to take forever.

Mooly said:

Another 'con' to the compressed image that emerged in use was that a simple transfer of files to a USB flash drive was quite slow, I assume as all the files had to be decompressed first....

Was this your SSD or an HDD that held the original jpegs? If an HDD, then de-fragmentation after applying the compression may have helped. As I said earlier, compressing an existing file often fragments it.

If you want to play with on-the-fly compression I recommend ditching NTFS compression and using compact w10 native one. Sure, it only can be read from withing w10, but it's a lot more optimized and faster. Better compression ratios overall too.

When comparing:

NTFS compression (NTLZ1): Low compression ratios (30% average). Fast when read. Slow when write. Introduces lots of fragmentation.
Compact compression (xpress4, xpress8k): Medium compression ratios (50% average). Very fast and multithreaded. Low cpu overhead. It will get disabled when written though. It does not introduce any noticeable fragmentation. Cannot be used outside w10. Instead of an Compressed attribute like NTLZ1 does, this one uses ntfs junctions to point to compressed data (something calle :wofcompressed or such), so you are creating a lot of ntfs junctions when compressing this way. Can be a pretty efficient compression for data read often but written rarely (Program files, static executables, etc).

By the way: We already did some mild study on THIS OLD THREAD.

Bree said:

Was this your SSD or an HDD that held the original jpegs? If an HDD, then de-fragmentation after applying the compression may have helped. As I said earlier, compressing an existing file often fragments it.

It was an SSD and was my main drive C partition in the laptop which holds all my user files in the normal way under docs/music/pics within Windows.

z3r010 said:

It wasn't me, I think it was Nigel

Well thanks to @Barman58 then