Windows 10: Any useful scenario for NTFS compression?

Thanks. So far, so good for me. Loading apps feel snappier when compressed and I have now 20GB free out of 40GB of partition size.

 

Hello. I have made a small benchmark regarding loading times and the different options.
I used MS Office 2010 Word x64

C:\Program Files\Microsoft Office\Office14\WINWORD.EXE - Uncompressed: 5.1257 seconds loading time
C:\Program Files\Microsoft Office\Office14\WINWORD.EXE - LZX: 4.0160 seconds loading time
C:\Program Files\Microsoft Office\Office14\WINWORD.EXE - Xpress4K: 2.9703 seconds loading time
C:\Program Files\Microsoft Office\Office14\WINWORD.EXE - Xpress8K: 2.6571 seconds loading time
C:\Program Files\Microsoft Office\Office14\WINWORD.EXE - Xpress16k: 2.5630 seconds loading time

It seems my i7 is pretty happy decompressing xpress16k.

 

How do you get those timings? I picked xpress16k just because some random person on the internet recommended it - they said it was faster for them and it seems it is for you also.

I'd like to do the same test as you but I don't know how to measure the load time.

Out of interest did you compress the C:\Program Files\Common Files as well or just Winword.exe? Do you have SSD?

 

Hello.

For doing the tests I used AppTimer, a free app from Passmark.
After setting the relevant compression settings on whole MS Office folder, I did a quick defrag with Defraggler and reboot.
After 1 or 2 minutes after hard disk stopped, I launched AppTimer and record its log file to desktop.
For the other rounds, I did the same, changed compression scheme again, quick defrag, reboot...
Even if Apptimer says "do you want to replace the log" it WILL APPEND new data to it.
And this is on an somewhat old SATA II Seagate mechanical HD. Not SSD. I have a lot of folder compressed (Program Files, Program Files (x86), any other software folders I have at root, Windows\Assembly, I have even compressed (FOR TESTING PURPOSES): windows\system32 and windows\syswow64 folders.
I have also packed the OS binaries too (with compact /compactos:always) and I haven't noticed any special slowdowns when booting (by checking event viewer).

I have to do some more tests though. And remember, as always, your mileage may vary.

Best regards.

 

Hello again.
After doing some home chores, I have done another benchmark. This time using a smaller app (Mozilla Firefox). Man, this benchmarks are quite time consuming but fun. Too bad I am unable to keep original TABS (sorry for the bad formatting).

MOZILLA FIREFOX 41.0.2

Size on Disk Compression Ratio Loading Time
====================================================

Uncompressed 85.2 MB (1.0 to 1) 5.2817s
NTLZ1 64.8 MB (1.3 to 1) 4.6882s
Xpress4K 59.0 MB (1.4 to 1) 4.9851s
Xpress8K 56.5 MB (1.5 to 1) 4.9538s
Xpress16K 55.2 MB (1.5 to 1) 5.1729s
LZX 49.3 MB (1.7 to 1) 5.6415s

Some assorted thoughts...

• I have included NTLZ1 compression just for comparison sake. This is the built-in NTFS compression that turns your folders and files blue. It's old, slow (specially for writing), single-threaded, and it will make your hard disk a fragmentation party. It didn't performed bad at loading times though.
• Everything that is compressed tends to load faster than its uncompressed counterpart. Obvious. Less reading from disk.
• Xpress8k seems to be a good middle-ground all around switch for both compression ratio and decompressing time.
• If you are low on disk space and don't matter longer loading times go for LZX. Its compression ratio is pretty good (usually around 40-60%).

 

I find the same - all compression methods were faster but xpress8k seems best for me.

This is opening WINWORD.exe (x64 from Office 2010 also) on i5 laptop with SSD. The OS was always in compressed state, I just changed compression on the Program Files and Program Files (x86) directories (ratio is just average of the 2).

Times are average of 5 runs using the Apptimer tool. Code: Compression Ratio Average Time (s) None 0.4097 NTFS 1.5 0.3672 -10% xpress4k 1.75 0.3886 -5% xpress8k 1.85 0.36396 -11% xpress16k 1.95 0.37702 -8% lzx 2.3 0.38908 -5%[/quote]

 

Thank you very much for posting your benchmark.

Best regards.

 

Hello.

These are some Windows folders that can be compressed too.

\windows\assembly (already mentioned)
\windows\inf
\windows\infused apps
\windows\installer (you may need to unpack it first with /u /s /a /a) (it was packed with lznt1 on my pc by default)

This will shave off about 2GB+ of free space.

 

That one is already compressed by compact /compactos:always (in my case from 50.4MB to 22.5). I'll add it anyway though, thanks.

In case you are interested this is what I'm doing at the moment.. It is pretty stable.

The compression is a bit trial and error (lzx for things like installer that are never used like installer, xpress8k for things that are like assembly). Obviously deleting is better than compressing when you can (WindowsApps and SoftwareDistribution\Downloads in particular). Fonts is reasonable extra saving (377MB to 249MB compressed) but you need to take/restore ownership.

Code: $compactDirectory = @( ("$envrogramFiles", "", "xpress16k") ("${envrogramFiles(x86)}", "", "xpress16k"), ("$env:homeDrive\MSOCache", "", "lzx"), ("$env:homeDrive$env:homePath\Documents", "", "xpress16k"), ("$env:homeDrive$env:homePath\OneDrive", "", "xpress16k"), ("$env:homeDrive$env:homePath\Downloads", "", "xpress16k"), ("$env:windir\Assembly", "","xpress8k"), ("$env:windir\Fonts", "NT SERVICE\TrustedInstaller", "xpress16k"), ("$env:windir\InfusedApps", "", "xpress16k"), ("$env:windir\Installer", "", "lzx"), ("$env:windir\Panther", "", "xpress16k"), ("$env:windir\SoftwareDistribution", "", "xpress16k"), ("$env:windir\System32\Catroot2", "", "xpress16k"), ("$env:windir\System32\LogFiles", "", "xpress16k") ) #------------------------------------------------------------------------------------------------------------------------------------------------------ function takeOwn-folder ($folder) { $toplevel = Split-Path $folder -leaf if (Test-Path "$PSScriptRoot\$toplevel.acl") {Remove-Item "$PSScriptRoot\$toplevel.acl" -Force -ErrorAction 0} icacls "$folder" /save "$PSScriptRoot\$toplevel.acl" /t takeown /f "$folder" /r icacls "$folder" --% /grant "%USERDOMAIN%\%USERNAME%"F) /t } #------------------------------------------------------------------------------------------------------------------------------------------------------ function restoreOwn-folder ($folder, $owner) { $toplevel = Split-Path $folder -leaf $parentPath = Split-Path -parent $folder icacls "$folder" /setowner "$owner" /t icacls "$parentPath" /restore "$PSScriptRoot\$toplevel.acl" Remove-Item "$PSScriptRoot\$toplevel.acl" -Force -ErrorAction 0 } #------------------------------------------------------------------------------------------------------------------------------------------------------ For($i=0;$i -lt $compactDirectory.Count; $i++) { $folder = $compactDirectory[$i][0] $owner = $compactDirectory[$i][1] $compression = $compactDirectory[$i][2] if(Test-Path $folder) { # take ownership if required if ($owner -ne "") {takeOwn-folder -folder $folder} Write-Host "Running " -NoNewLine Write-Host "compact /c /s /a /f /q /i /exe:"$compression $folder"\*" -f White compact /c /s /a /f /q /i /exe:$compression $folder\* #restore ownership if ($owner -ne "") {restoreOwn-folder -folder $folder -owner $owner} } }[/quote] What I've had problems with are these 3 Code: # ("$env:windir\System32\DriverStore\FileRepository","","lzx"), # ("$envrogramData","NT AUTHORITY\SYSTEM","xpress16k"), # ("$env:APPDATA","NT AUTHORITY\SYSTEM","xpress16k"),[/quote] Not sure if I've got the ownership wrong or what but windows doesn't work properly if I compress these.

I'd like to compress DriverStore as it is big but my screen goes all funny if I do...

 

Sometimes when I install the OS, I choose to use NTFS compression across the entire System partition (On MBR/BIOS I combine boot and windows partitions).

I do this after install, but before the final reboot via command prompt with something similar to:
Code: FOR /F "delims=*" %I IN ('dir /b /s "C:\*.dll") DO compact /C /A /EXE:XPRESS18K "%I" FOR /F "delims=*" %I IN ('dir /b /s "C:\*.exe") DO compact /C /A /EXE:XPRESS18K "%I" compact /C /A /S:C:\ compact /U /A /S:C:\boot compact /U /A /S:C:\Windows\boot compact /U /A C:\Windows\System32\winload.exe[/quote] A few things you cannot compress and successfully boot on MBR/BIOS are:
\Windows\System32\winload.exe
\Windows\boot\*
\boot\* (assuming you combine boot and OS partitions like I do)

Everything else I believe is able to have compression applied.

 

I would love MS or someone else would make a nice GUI and improve the compact command.

 

Hello guys.

A question crossed my mind. Does anybody know if Xpress DECOMPRESSION TIME is the same for al variants (4k, 8k, 16k)?
I am asking this because right now I am quite satisfied with the 8k compression ratio/speed, but I could go for 16k just for the extra space savings.

 

Isn't that what testing load times of Winword.exe and firefox you did earlier does? For the first load this will read from disk and decompress into ram. This guy says xpress16k is just as fast Windows 10 Compression - Page 8 and (completely unscientifically) I can't feel any difference...

I guess you could test it by decompressing something big (a wim or a game or something) but how this would apply to real use I don't know as if you've got enough RAM pages will be decompressed and stay in memory anyway until something pushes them out.

Perhaps looking at frame rates in a game would be a good test? I don't have any so I can't test that.

 

Thanks. I am asking because the tool we used to measure loading times (AppTimer) doesn't take into account cpu usage, which would be nice to have too. I will test packing a game or something.

Best regards.

 

I have made a quick test. Compressing a huge 4GB+ Neverwinter Nights 2 campaign I am currently playing. Although the game sits on my SSD, these external files are on my SATA II mechanical hard disk. I do not trust SSD tests because they are pretty fast already and it makes more sense on HD anyway.

No great differences between Xpress8k and Xpress16k

Both compression ratios were 2.2 to 1. Loading times (using a physical chronograph) were 18'69s and 19'54s respectively. If we take into account some error margin, the difference is less than a second.

Some other apps. didn't get any benefit in size from going to 16k over 8k. Defraggler went from 1.8 to 2.2 though.

I have not been able to determine if loading times are the same or not. Maybe someone could supply a different way of testing (or showing some documents or something).

Right now I am sticking to 8k to be on safe ground.

PS - By the way. When we did our earlier tests we didn't take into account Windows Prefetcher .pf files. They could add some randomness to loading times I think. I think we should have deleted the associated .pf files between runs.

Best regards.