CompactGUI - Easily reduce the footprint of programs and games on Windows 10

​

This tool is an open-source standalone visual interface to make using the Windows 10 compact.exe function more available to more people. It's intentionally designed to only compress folders and files.

Whole drives and entire Windows installations cannot be modified from this tool — users seeking that functionality should use the command-line version built into Windows (this is intentional).

The compression used by compact.exe is similar to the built-in NTFS compression in that it is transparent. Compressed files and programs can still be accessed as if nothing has changed and show up in Explorer as they normally would — they'll just be decompressed on the fly at runtime. However, the newer algorithms are much more efficient than NTFS (LZNT1).

Download
Download / More information on GitHub

Uses
Use this tool to:

• Compress program folders (e.g. Adobe Photoshop: 1.71 GB --> 886 MB)
• Compress game install folders (e.g. Portal 2: 11.8 GB --> 7.88 GB)
• Compress any other folder on your computer except those in C:/Windows (use the command line for that)

For most modern computers there will be no (or very little) performance loss. Those with older HDDs may even see a decent performance gain in the form of reduced loading times as the smaller files means it takes less time to read programs and games into RAM.

Spoiler: More Game and Program Compression Examples

Extra Features

• More accurate reporting than the built-in Windows command-line tool (as there are some bugs with parsing that Microsoft needs to fix)
• Analyze the status of existing folders
  
• Integration into Explorer context menus for easier use.

Screenshots

Spoiler: CompactGUI Screenshots

Spoiler: Context Menu

Background
Windows 10 includes a little-known but very useful tool called Compact that allows one to compress folders and files on disk, decompressing them at runtime. With any modern CPU, this added load is hardly noticed, and the space savings are of most use on those with smaller SSDs.

As program folders and games can be shrunk by up to 60%, this has the added bonus of potentially reducing load times - especially on slower HDDs.

More information on the inbuilt Windows function can be found here

Compression Options
By default, the program runs Compact with the /EXE:XPRESS8K flag active. This provides a good balance between compression speed and size reduction. The default that Windows uses is /EXE:XPRESS4K. The options available are:

• XPRESS4K: Fastest, but doesn't compress as much
• XPRESS8K: Decent balance between speed and compression
• XPRESS16K: Slower, but compresses the most
• LZX: Okay technically this one compresses the most, BUT it is for compressing folders that are hardly used and are just being stored. Please don't use this on game or program folders.

Additional Notes
In my testing, using any of the XPRESS modes has no discernible impact on CPU performance when the compressed program is run (Using an i7-6700HQ). Here's the output tests for Adobe Photoshop:

Spoiler: Adobe Photoshop CC 2017 Performance

However, if your processor is especially old, you may find that performance is worse when folders are compressed with 8K and 16K. Use 4K instead. Despite this, I've successfully tested it on an i3-370M from 2010, and it had no issues with performance on any of the compression modes.

 

This is snake oil taken to the next level. Compressing any file means the files have to be uncompressed before they can be used. Stay away from this people.

 

Snake oil? Bit harsh. It has its uses (mostly to decrease hdd throughput bottlenecking and increase effective storage pool for archival type data) and this looks better than the integrated windoze on the fly version

I'd like to see file write overhead tests to gauge whether there's a "negligible" impact there too, since encryption is usually a lot more computationally intensive than decryption.

 

@tilleroftheearth please step in

 

Surely good intentions. But I'd definitely opt for larger hd \ ssd (or more cloud storage, ...or reclaim lotsa space by deleting\offloading all that forgotten trash that somehow ends up everywhere :0)

Long ago, when large hd's were immensely expensive, a reliable, safe 'live' compression would be very welcome, but with todays prices? Potential gain not worth the experimentation risks. imo. That said, others may put it to good use.

 

Yeah; snake oil may be a little bit harsh. But it isn't anything I would test, let alone recommend.

Any third party program that interferes with the O/S's (built in) abilities is suspect in my eyes.

Especially when a significantly larger drive is a mere few $$ away for the few GB's you may save using these type of compression techniques.

If the need to save a few GB's is that great; back up your data, cross your fingers and give it a shot. But I would recommend saving for a bigger system drive and/or external drive where you can move your DATA to instead.

Just don't expect to be able to do standard recovery procedures reliably if/when that drive fails (please don't do this on your data - ever).

The biggest issue with this is that if there are any glitches in the use of the system - and inevitably there will be - it will be impossible to tell what you're tracking/fixing down... if it's possible to fix anything in the first place.

Hardware (i.e. a bigger storage subsystem in this case) is always superior to a software solution.

 

Ouch, but if this is snake oil, then it's snake oil that's built-in to Windows. All the program does is send the arguments to compact.exe and capture the output.
As for the compression, yes it has to be uncompresed. This is done on the fly, similar to how the LZNT1 compression works if you select "Compress this folder to save space" in the properties window of a folder in Explorer, so a file that is being sent to the CPU will be unpacked as it streams in from the drive. Windows 10 even added the /EXE flags especially for compressing programs - it says so if you run compact.exe /? from the commandline or read the docs here.

The benefits of using compact.exe over the LZNT1 compression are a bit mixed. For one, compact.exe is multithreaded, so it's much more efficient. On the other hand, only compact.exe /c (without the /EXE:Xpress flag) matches LZNT1 in being able to compress new files as they're added to or updated in the selected folder.

It doesn't really interfere, just runs the in-built program and captures the output. The source code is visible on GitHub so you can see there's no sneakery going on
I do agree with you entirely that a hardware solution is always better, but Microsoft added this feature in, so why not use it to salvage some GBs while waiting for the cash to upgrade?

The main use for this is on programs and games, so loss of data shouldn't be an issue in those cases. Also Microsoft documents the use of compact in a few places, as well as the /compactOS function, which uses Xpress4k but on the Windows installation. They even have a guide on using it for image deployment, so I'd hope they've considered recovery.

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/compact-os

 

Its a nice find but compressing and decompressing takes a lot of cpu power.
Unless you're running short of space on small sized SSD or ROM compact isn't needed at all. I'd compress the files only if its too old.

 

@Vasudev actually if your processor is relatively new, the performance impact should be minimal - in testing that I've done, there's been no noticeable impact on performance. In fact, Microsoft documents the XPRESS algorithms as being geared towards performance rather than compression: here and here
Most CPUs can actually decode faster than they can stream data in from the drive, so for HDDs you might actually see an improvement, e.g.

According to this guy an i7-3720QM can decompress XPRESS at rates between 320MBPS and 720MBPS. That's for an old, mobile chip too, newer ones (especially desktop ones) will be much faster, but let's use these values. An uncompressed file is read at 2000MBPS.

Let's say you have a 1000MB file that gets compressed to 700MB.

Let's now take an average SATA SSD's maximum sequential read speed - 520MBPS. This falls right in the middle of the decompress speed zone of the CPU, so performance might be slightly lower as the CPU might be receiving some data faster than it can decompress it - leading to a stutter.

• Uncompressed: 1000MB read @ 2000MBPS across a 520MBPS interface = 1.92s to load
  
• Compressed Worst Case: 700MB @ 320MBPS across a 520MBPS interface = 2.2s to load
  
• Compression Best Case: 700MB @ 720MBPS across a 520MBPS interface = 1.35s to load

Now let's take a HDD, optimistically running at 160MBPS.

• Uncompressed: 1000MB @ 2000MBPS across a 160MBPS interface = 6.3s to load
  
• Compressed Worst Case: 700MB @ 320MBPS across a 160MBPS interface = 4.4s to load
  
• Compressed Best Case: 700MB @ 720MBPS across a 160MBPS interface = 4.4s to load

So, even on an older mobile CPU there are benefits if compressing the file on a HDD. Even the slowest decompression algorithm was able to load the file faster than the uncompressed version because the speed was greater than that of the HDD.
On an SSD, it's a bit more on the fence, but still, these are all highly optimistic values.

As for CPU usage - no increases that I could note, even on an SSD, however my CPU is definitely much more powerful than the 3720QM used above. You can see the CPU usage for Photoshop in the original post.

Other users have tested this, and only a 4 or 5 games (out of the 950 submitted) have been troublesome, and these ones might be using virtual disks to store the game on.

 

I don't know the test, methodology and full platform spec's you used in post #1, but I can see from the 'numbers' that vs. the uncompressed data, the compressed method is not always faster - even in your example.

I tested this myself on a handful of systems over the last couple of hours.

Verdict: not for me. Just too laggy after using the system(s) for anything over 15 minutes in my normal workflows.

Programs I tested on:

Adobe Acrobat Pro
Accounting program
LR
JAVA folder
iTunes


In all of the above scenarios; I compressed the above program folders with the default settings offered by the CompactGUI program, rebooted the system, let it sit idle for 15 minutes and then proceed to use it in one of my normal workflow/workloads. Note that I normally close all programs between uses during a session - that means I may open certain programs up to 20 times in a 15-30 minute period...

With four identical platforms; I used different settings (other than defaults) for each one.

I left one platform untouched to compare to.

Within half an hour of rebooting and using the programs above; the system became noticeably laggy to me vs. the untouched platform. So much so that I didn't need the untouched platform to compare to.

In my situation; I saved a whopping 1,300MB of space to get a more laggy system when I used the programs as I normally do (and each had been compressed).

The pertinent system spec's I was using: i7 QC, 16GB RAM, 1TB SSD, Win10x64Pro (Fall Creators Update).

While the theoretical 'scores' you calculated below (which I didn't double check, btw...) may seem to indicate a benefit - real world workflows don't support it (at least not my rwwf's).

What is most telling to me is that this program doesn't allow me to compress the Windows folder (it says use the command line...). In other words; don't mess with O/S defaults - they're set that way for a reason.

When uncompressing the folders (then rebooting and waiting ~15 minutes again) I immediately felt more directly connected to the O/S (i.e. it was more responsive) - even without using the programs I had compressed - with all the test platforms. Not only did compressing make those programs laggy; it made the rest of the O/S laggy too. I can only conclude that the CPU is not the only indicator of the 'load' the decompressing does to the system overall - but it was a relief to see the 'snappiness' that I'm accustomed to from my systems return.

YMMV.

 

@tilleroftheearth thanks for running those tests It really does seem to be an "it depends" scenario a lot of the time, especially when used on programs that are used daily. For games, it seems more clear cut - it either works fine, or it doesn't.

FCU seems to have a few issues around system lagging after a couple of hours of use, but it can't be that since your speed went right back to normal after uncompressing

You say you used an i7 QC - what exactly is it if you don't mind me asking?

It really is tough to call it one way or the other.

It does that because I intentionally designed it that way so that users don't accidentally go compacting boot files - bad things happen if you compact those.

 

Yeah; everyone needs to test in their own 'normal' usage (don't do bm runs... useless 99% of the time to predict rwu).

These are my older platforms which run on Ivy Bridge i7-3612QM processors - but they're still used on less demanding projects (and therefore kept updated and ready). Didn't want to cause issues with current/production platforms though.

 

I tested this on an uncompressed backup of working data, a 45gb mix of media, photos, docs, it took 90mins to compress and then ~45-60min to decompress.

Saved 3Gb, express16K setting. Didn't go above 70% on one thread and about 30% on a second, out of 8 logical cores. The drive, while a budget MLC SSD, I know it can sustain a solid ~150mb/s activity in the long term. CPU is i7-3940xm @ 4.2ghz, 32gb ram.

Is there some setting to get it to more aggressively multithread? 45gb/90mins = 500Mb/min ~= 8Mb/sec throughput is completely worthless to me if this is how it behaves in normal use

 

@bennyg which version of CompactGUI did you use? older versions used an inefficient output for the console and thus were slow if you used it on large folders. V1.4.0-rc1 and above should be much faster.

Also, is that 150mb/s speed for read only? don't forget that compact.exe has to both read and write, so your throughput will be at least halved. Not saying it would make it 90 minutes slow, but just wanted to point that out

 

FYI
version 1.3.5, I didn't have console output on
I didn't take any screenshots but from memory the drive active time graph showed it spent most of its time <25% utilisation, sometimes 100% for bursts (up to ten seconds) per few minutes (large files I assume)
Folder in question is 45.4Gb total, ~25000 files, ~4600 folders

 

Thanks for doing this. That's what I was saying in the beginning, under no circumstance can a compressed file/folder be a good thing. It's always gonna be slower as the file has to be uncompressed first. Hence why IMO this program and thread is a major fail.

 

You're welcome Phoenix.

I don't think this makes the program and thread a fail though.

It does what it says it will do and in the end, it is just for an obscure Windows built in function. I have played with the command line version built into Windows a long time ago, back then I actually had to re install the O/S afterwards (can't remember, but I may have compressed the Windows folder then...).

In my workflows, I open and close many programs many times per work session on the platform I'm using. This may have exaggerated the effects of the decompressing needed (idk). In some situations, this may still be a worthwhile tradeoff while saving for the bigger drive or newer platform that the workflow is indicating is so desperately needed.

Edit: sm2596, what does FCU mean in your post#11 above? Ty!

Take care.

 

I believe that stands for Fall Creator's Update.

 

I'd like to chime in and say that if you are on a budget and you have a small SSD, this application has little to no implicit performance hit on your CPU.

Simple said, for the majority of people, this might not do much, but being able to compress your steamfolder using a simple app taking advantage of the same code as the OS is great.

My little brother SSD of 120GB if filled to the brink, I compressed FIFA18 and have had 0 issues with it so far, that game is 56GB and it went to 42GB, so success.


Again, this depends on your preferences. This is a last/temporary resort solution for the lack of space. Remember, this will take a toll on your SSD's wear and take up a small amount of CPU performance.

 

I just found this little program called "Compact GUI" that compresses game files. I just tested with the game War Thunder, that game folder was 28.1gb, its now at 19gb, I just saved 9gb of space on my SSD. The game loads the same has before. You cant use it to compress a single file, you will need to compress the entire folder.

I am know trying with my Steam folder at over 1.1tb on a normal HD. I am sure it will take some hours to complete.

 

Nice find! gonna give that a try.

 

The program is build into windows 10, its called compact but that is with command lines. Compact GUI is more user friendly.

 

Gonna test it, sounds like a dream to me.

 

This one https://github.com/ImminentFate/CompactGUI/wiki/Compression-Results:-Games?

 

yea that one

 

There must be some penalty? Extra CPU use and some delay.

 

Are there any issues when Steam updates the game files?

Agree with HTWingNut, there's gotta be some penalty, though I doubt it would be as bad as loading times with encrypted games like Forza Horizon 3 (yeesh).

 

I just used windows to compress (Windows 7). Go to Program files (x86) right click the file you want to compress, properties, advanced, and check compress files to save space. Seems to work. I think I saved about 7 gb on BF1 this way.

Charlie

 

When Steam updates the game files, it will save the uncompressed version of any files it changes, so you'll have to recompress afterwards.

That method uses the old LZNT1 compression, and is inferior with respect to performance in games and programs, as it is single-threaded and prioritises compression ratio over runtime performance. The " /EXE" flags in the compact.exe tool are designed around use on executable files, so they're optimised for performance over compression ratios but still do a really good job.
Even the basic " compact.exe /c" option is better than the right click menu option, as it's still LZNT1(I think) but it's multi-threaded so the performance hit should be lower

 

I find it really hard to believe any type of real-time data compression wouldn't affect performance. Idea is great though

 

Obviously it's going to have some performance impact, nothing is free - however as processors have become more powerful, the impacts become negligible in many situations.
Look at Anisotropic filtering on GPUs - 15 years ago increasing AF to 16x would cause your FPS to drop, but almost any GPU from the 600 series onwards can max out their AF with no performance impact.

Likewise with CPU progress, you reach a point where certain operations become efficient enough that their impacts are negligible. We're not quite there yet with compression, but we're pretty close.

Also, note that Windows 10 applies OS level compression by default on some low-capacity SSDs (you can check your status by typing "compact.exe /compactOs" into CMD or Powershell. It wouldn't make sense for Windows to do this if there was going to be a significant performance hit, especially since this compression mostly applies to low-power, low-space hybrid devices.

If you want some benchmarks, have a look at these (sadly some of these didn't do FPS comparisons which are more important than load comparisons :/)
Fortnite
ARMA 3 (there are framerate comparisons a bit further down)
CSGO
Rising Storm 2

I've done some more testing with a few games, but it takes time (which I don't have at the moment) to do proper benchmarks and create analyses of the results - for the most part, I'm relying on user feedback for games that show issues (most of these seem to be games that store themselves in one file like Guild Wars 2) but there haven't been many complaints of performance loss.

 

Sure, I understand! But one is GPU taxing whilst the other is CPU and HDD taxing (obviously no one would use this in an HDD I'm assuming) so even with SSD writing speeds I'm guessing the constant compression and decompression even though it frees up space, it taxes up a lot on reads and writes? I may be wrong though

 

Ah, I see where you're confused; the compressed files don't get decompressed and re-written onto the drive, that would be horrible. Instead they're decompressed on the fly as they're needed, and stored in RAM exactly how they normally would be. Here's a diagram to illustrate it

So during usage, there's no increase in read or writes to the drive