I could understand you being concerned about disk space
but disk cache space ???

Maybe I am being a little paranoid here, he he. Not cache space per se but efficiency. Less disk thrashing is always welcome. It feels snappier somehow.

The on-disk cache would be used more efficiently, and there'd be less data to read from/write to the disk anyway, but I'm pretty sure the data is decompressed before storing it in Windows' own disk cache.

I have made some more tests. To sum it up...

NTFS compression advantages:

+ When data is compressible enough you get amazing space savings. 14GB+ for my 100 GB games partition. Program Files gives you about 1GB+.
+ Slightly less disk I/O and less disk thrashing.

NTFS compression shortcomings:

+ More CPU I/O. Can be a problem for slower CPUs.
+ Reading time isn't improved or little at all, specially for already fast hard disks.
+ SLOW writing time accesses for data frequently modified. You should not compress it.
+ Increased fragmentation levels.
+ When making a backup of a compressed partition the resulting copy will compress poorly and it will take more space.

PS - NTFS compression would be great if it would achieve GZIP or any DEFLATE compression gains. It would be pretty slow for writing though.

I only use the NTFS built-in compression for non-gaming needs like documents and other less used files/apps.

Besides, storage space is dirt cheap now a days, well here in the states that is 😉

Also, I'm not going to wait the days it would take for my 1.3TB Plus STEAM folder to compress 😜

I have found this nice app.

NTFSCompressor

It allows for fine-tuning using NTFS compression.

not really "fine tuning"... there's no compression ratio adjustment... all the tool is is a utility that scans the entire hard drive, find files that meets your search parameters and compresses only those files

frankly, I'm not too impressed at the results

There is a slider for adjusting desired compression ratio. Default value is not compress files with gains lower than 5%.

Yeah this app. is at very alpha stage and it seems it hasn't been updated since 2005. The sources are there but I do not know how to compile them.

that's not a compression ratio adjustment... it's simply a limiter for the utility to calculate if a file can be compressed greater than x%

true compression ratio adjustment will be changing how much you want to compress the file.... take a zip archive for example... "store" is no compression, but "normal" is just some compression, while "maximum" makes it attempt to compress the files as much as possible but increasing performance overhead

Remember to defragment your files after compression or you run into the 64 kB chunk fragmentation problem. It is also mentioned here:
https://secure.wikimedia.org/wikipedia/en/wik … ile_compression
Without defragmentation you will get a lot of small free clusters, which may be filled with later writes.

So in basic theory, if you compress each 64 kB chunk of a file to 32 kB, then you get 32 kB filled + 32 kB free and so on.
The head has to go by the same whole path to read all data of the file. Now if you write additional smaller file the situation gets drastically worse since they may be filled in all the small free gaps.