The two compress options aren't the same, but more on that later. The first thing to note is that compressing data is not the best solution when the drive is full. NTFS will suffer badly from lack of space, because there are no more good places to allocate new files or move old files around and fragmentation will increase. Especially when it begins to use the reserved space for the MFT then the MFT might become fragmented and worse things may happen
So at first some other things need to be done:
Reduce pagefile size. Your system will crawl to death if just 1-3GB of pagefile is used. But you can't disable it entirely (at least not a good idea), so a lower limit of 1GB and upper limit of 4GB might be a fine choice. That will save you a few GBs compared to the default setting. You can add more page files on other drives if available
Reduce hiberfil.sys size. Open cmd as admin and run powercfg /h /size 40 to set the size to 40% of your RAM. From Windows 7 onward it defaults to 75% the amount of RAM, so setting it to 50% will save you 3GB of disk space. You can also turn it off completely with powercfg /h off if you don't need hibernation, or if you want to turn off hibernation while still enabling fast boot then use powercfg /h /type reduced which shrinks the file to only 20%
Clean up the WinSxS folder with the DISM command. For more information read How to Reduce the Size of Your WinSXS Folder
Check your data usage and move/remove some unnecessary files
You can use some tools like WizTree, TreeSize or WinDirStat. You'll be surprised to see how big some files/folders are, esp. some temp and cache folders. WizTree is likely the fastest and more correct one because it reads information directly from the MFT. Remember to run them as admin
For more suggestions see How can I visualize the file system usage on Windows? or The Four Best Free Tools to Analyze Hard Drive Space on Your Windows PC
If you have another HDD then don't store too many unnecessary things on the system drive. Leave it for apps and files that need fast access
- Move the documents folders to another drive
- Move the store app install folder and save folder
- Some other folders can also be moved by changing some configurations, or by creating a symlink. For example many folders in Windows\System32 or Program Files can be moved to HDD. Some tutorials on that
Delete Windows.old if you don't need to roll back to the previous version, or back it up and remove it
Just doing the first 2 steps above saves you tons of space immediately. Then after doing everything if more space is still needed then just compact the OS. By deleting files first you also make it faster to compress the OS. The performance difference is often negligible
The CompactOS feature does indeed worth it on small SSDs compared to HDDs. My old laptop has a 1TB HDD with a 32GB SSD cache. I've tried installing Windows onto the 32GB SSD and it ran noticeably smoother than on the HDD+cache
Regarding your questions:
I'm not sure whether there are any performance penalty associating with compressing the OS drive.
Compressing files always have a CPU time penalty. That doesn't mean that it'll be slow though, since on slow storage devices like HDDs that penalty might be far less than the wasted time on accessing/reading the data from HDD. That's why sometimes compressing easily-compressed data will make it faster to access. One example is that hibernation in newer Windows compresses data before writing to disk, which makes shutdown much faster because the CPU can compress faster than the drive can write
The difference may be less obvious on SSDs, but there's no way to know that for sure except benchmarking for your specific situation. Each use case is different, and not all disks are created equal. For example old SSDs may run at only ~200MB/s which is just about as fast as an HDD nowadays (but their obvious advantage is the very fast access time and high IOPs), whereas newer algorithms like LZ4 (which is used in Linux's zram) or Zstd can sustain ~2-5GB/s which is even faster than modern SSDs. See
There's often no need to worry, because Windows will do a benchmark while installing to assess whether CompactOS should be enabled or not. Although after installing apps and things that benchmark result may not be correct anymore and you may want to do a reassessment yourself
And I'm not even sure whether this option is the same with "Compress this drive to save disk space" at the C drive property as per below
Basically both use the compression feature of NTFS and can be configured by compact.exe, but there are many major differences
The "Compress your OS drive" (i.e. CompactOS) feature uses the newly introduced compression algorithms XPRESS* and LZX in Windows 10's NTFS. They're designed for efficient storage for "static" files that don't change much (like executables)
OTOH the "Compress this drive to save disk space" feature uses LZNT1 algorithm and is designed for compressing frequently changed data files for optimum performance. That means it'll be faster but the compression ratio will not be as high. It's like checking the "Compress contents to save disk space" option for all files and folders on the drive
Files compacted by CompactOS will not be marked as compressed (either shown in blue or with double arrows) if that feature is enabled
CompactOS compresses selected system files, while NTFS whole-disk-compression compresses every file on the disk
In fact you can use the new algorithms for CompactOS for any user files, but you can't do on-the-fly editing on them, as they're designed for static read-only files like mentioned above. Writing to those files will uncompress them. For more information about that as you can read NTFS compressed folders: is it possible to tweak compression ratio?
The random on-the-fly write ability also makes the "Compress this drive to save disk space" even worse for your use case, because it increases fragmentation significantly. CompactOS compresses the whole file (AFAIK) like a *.cab or *.wim file so you'll get a contiguous file. OTOH NTFS transparent compression works by splitting the file to 16-cluster chunks and compress them separately. Each chunk will be a fragment after that, which makes your contiguous file now has tons of holes between the chunks.
You may think "why worry about that" but SSD's complete immunity to fragmentation is a myth! For fast operations and small metadata size modern file systems store files as extents which is a file's contiguous section on disk, so each fragment will be stored as a separate extent. Hence a file with 1000 fragments will consume more space in the MFT for the metadata compared to a 2-fragment one, and the CPU also needs more time to parse them to get the next block of data. As a result Windows defragmenter still does some mild defragmentation for SSD drives to optimize metadata usage
Further reading:
The link given by Xen2050 is also good. It shows that even with the drive compression feature the difference is not that much, and in some cases it'll be faster, as I mentioned above
