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.
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 used by Compact are much more efficient.
Compact GUI, 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.
Compact.exe/Compact.exe GUI
Pointless. Just buy more storage.
It's like Windows didn't have filesystem compression since the 90's already.
Thanks for posting the obvious, newfag.
Will it compact new files or modified files in the folder?
Nice try, seagate.
This
a 500gb ssd is like $200
It's pretty fucking useless compared to NTFS compression, as it UNCOMPRESSES files you access, even when it's transparent.
I.e. you have a small SSD, with NTFS compression you could fit 170GB on that 128GB SSD with 1GB free space, but with this, you technically can, but once you try to access a file that's bigger than 1GB (the free space you have) you will run into a wall.
This is only useful for cold storage, something we could already do for ages, for on-the-fly transparent compression, the shitty decades old NTFS way is still better for actual use.
Well I thought it was helpful OP. Thanks for sharing, I'll check it out tomorrow.
In what universe?
In this universe. I can find them easily for 150€ and that's with 21% VAT added
good to know OP ignore the other faggots
I'd say this one.
is pretty valid point imo
I agree NTFS compression is better for large rarely used files. But from what I see this tool maybe has its uses on large games/programs
>With any modern CPU
microsoft Joo enters the board: be Good Goyims and landfill all your computers from more than 6 months ago, you can replace them with "any modern CPU" and incredibly over-inflated RAM prices right now for only 3000 shekelbergs
So much tool, many amaze, such useful and magic pixie dust. This Windoze 10 being many shizznitz. Wai (you) goyims not all being cool and using such an froody app?
Samefagging this hard. Whew, laddie.
>I agree NTFS compression is better for large rarely used files
you got that totally the wrong way around
>But from what I see this tool maybe has its uses on large games/programs
no, the problem is, that if you access the file, like a game accesses its data files they will be uncompressed onto the drive, ntfs compression does not have this problem, even when it compresses less
why would agree with OP but is totally against it and calls it shit?
pretty dumb to samefag saying its great and then say its shit? wouldn't it?
>it UNCOMPRESSES files you access
Well of course. How are you supposed to read a file without decompressing it?
>once you try to access a file that's bigger than 1GB (the free space you have) you will run into a wall.
It doesn't write the decompressed file back to the disk. Where'd you get that idea from? It's done on-the-fly in memory.
>This is only useful for cold storage
It's useful for any file that you're only reading from. The compression has a much better ratio than NTFS compression but it's not designed for files that are often updated.
Please educate yourself before spouting nonsense.
...
why would you buy 500gb just for storing games? 1 game will be like ~100gb in 2018
>Well of course. How are you supposed to read a file without decompressing it?
On the fly in memory, without uncompressing it onto the disk, like NTFS compression does it.
>It doesn't write the decompressed file back to the disk. Where'd you get that idea from? It's done on-the-fly in memory.
Windows 10 Compact.exe does just that, that's the point, it decompresses the file back to disk.
Have you even used it? The whole point of the post was to point out the flaws.
>It's useful for any file that you're only reading from. The compression has a much better ratio than NTFS compression but it's not designed for files that are often updated.
No, it's not really better than normal archival with compression is, it's NOT like NTFS compression.
>Please educate yourself before spouting nonsense.
You should have tested things yourself before, now this statement only makes you yourself look like an idiot.
I doubt that, currently games are from 60 to 80, plus how many games do you play constantly anyways?
1-2 kek
>the added load is hardly noticed
Oh but it is. Winshit 10 is already slow as fuck running all that background snoopware.
I still have an i7-930 and it works fine for me, that's a 7 year old processor.
The new final fantasy for windows is 170gb
what happens if you have to uncompress more than your disk space has available
lol
This was reported to be false
>Windows 10 Compact.exe does just that, that's the point, it decompresses the file back to disk.
No it does not, you can see this easily with the resource manager, anything that ends in ":WofCompressedData" is a file compressed with compact, when reading a file like this monitor your writes, there shouldn't be any related to it for read operations.
Where did you get the idea that this is disk to disk and not just memory mapped io?
>No, it's not really better than normal archival with compression is
Objectively wrong, the xpress methods beat it in performance and compression while the lzx methods beats it in just compression.
Test it.
>all compression algorithms are equal
Does anyone know why Unity and Unreal engine games compress so well?
Storage is less valuable than CPU power. So no, this is retarded unless.
Compression is a 1 time thing, decompression uses significantly less cpu and basically gives you a free read performance boost on files that compress well.
This kind of thing isn't uncommon for filesystems, people do stuff like this on ZFS with LZ4 all the time.
Decompression still uses CPU power. It's not worth it in most cases.
Compact is only usefull for the OS itself since the windows folder gets bigger and bigger every single update and everything the OS needs stays in ram anyway.
For your day to day use applications don't do it, reading performance is slow as fuck compared to an SSD or even HDD sometimes.
>reading performance is slow as fuck compared to an SSD or even HDD sometimes
How do you figure that? You're loading less data off the disk, at worst it would be the same speed, at best it would save N bytes worth of iops.
Because the on-the-fly decompression is limited to a single thread and it has some overhead on top of that. I did write a program a good while ago to test it and it looks like 110-120 mb/s is the limit for a i7-4790 and about 40-45mb/s on a old i5 ultrabook.
For whatever reason microsoft never changed that since the NT4 days, they could at least add some threads since decompression is made in 4k blocks.
Users are experiencing reductions in game load time after compressing game folders. It's efficient on the fly compression which can have huge benefits in reducing disk usage. On top of increasing available storage, it reduces overall read time when loading from your disk
>Test it.
Please do, I've known and used compact.exe for over a year.
Try compressing a huge game or program folder, even better a virtual machine image, check how much space it takes on your disk, then run it and check again.
If you aren't using an SSD during gaming and have a cpu Fromm there last 5 years your read/write is usually your bottleneck. Reducing read time at the sacrifice of a small amount of unused cpu is a huge benefit to avoid stutter and drops
I have, it works well for a lot of the games I own, Killing Floor 2 is particularly great with this. Why do you think it's somehow worse than LZNT1?
The only thing LZNT1 has is raw decompression speed performance but in practice xpress still loads files faster on average because it's ultimately loading less data, on average, the disparity between compression performance is large enough to make up for the marginal speed differences between them. If you compare already in memory LZNT1 will win but you have to remember the files have to be pulled from disk in real world applications, they're not going to already be in memory.
I highly doubt your devices are CPU starved, as for power consumption it's not likely to effect anything, if you're loading files you're utilizing the cpu already, I doubt there would be any significant voltage changes.
I'd like to see some numbers though.
Not OP, but I think it's only worth it on bandwidth limited scenarios, like playing games off a microSD card, like GPD Win.
You're really not going to run into space constraints that this would be worth it. Unless you can't afford storage.
>wasting CPU power for reading while gaming
Literal retardation. You don't need read speed for anything other than loading maps or other "initial setups". It's not going to give you much performance. If it did then Linux would outperform windows in gaming.
Tl;dr performance won't change at all, only loading times.
>Why do you think it's somehow worse than LZNT1?
>Missing the point this hard
Nobody has talked about it being better or worse, it's worse for the simple fact that the filesize on disk expands when the file is in use, it's not the same way "on the fly" as shitty old NTFS compression.
>Linux would outperform windows in gaming
On average, doesn't it?
>performance won't change at all, only loading times
That is performance though, when we're talking about compression and reading data, we're talking about read performance, what did you think that meant?
>the filesize on disk expands when the file is in use
Where are you getting this from?
>it's not the same way "on the fly"
The new method is just a reparse point to a compressed data stream, it decompresses from disk to memory when reading. How is it different?
Probably benefits HDDs with an RPM below 10k.
>On average, doesn't it?
Wait, are you serious?
What a useless post. Now there's 2 useless posts, great.
>For your day to day use applications don't do it, reading performance is slow as fuck compared to an SSD or even HDD sometimes.
LOL no
and you would have to perform it every single time there's an update, however small
>Where the fuck are you living?
130$ for 2TB here, pal.
It does desu.
CPU performance is slightly better on Linux (on Intel at least), so if you're gaming on integrated graphics or playing a CPU intensive game you should get better performance.
The file system is better on Linux, so loading times are by default better on Linux.
On GPUs which have proper driver support the performance difference is around 1% between windows and Linux. When comparing openGL vs openGL or Vulkan vs Vulkan on both systems. Adding directX into the equation changes things depending on how developers optimize the game and which versions of dx and oGL are used.
The only places where Linux loses are badly ported/optimized games, wine ports (aka emulated games), or dx11/dx12 vs oGL.
solid state drive you inbred.
Why are you even on a technology board?
>wine ports
I've seen cases where running the same Windows game on Wine vs Windows native has shown better performance results, so even there it can win. I'm sure that scenario will improve as they optimize their Wine implementations as well.
The problem is that even though you can have a better performance on linux+wine, those better performing wine "ports" are community based. As in, someone made a patch and a config file for that specific game and for their hardware (like the DOOM benchmark which shown wine beats windows performance). But most (90%+) developers are lazy and just slap the basic wine wrapper onto their game and ship it to Linux, not even optimizing the game for Linux. The sad truth is that the gaming community is cancerous and developers are lazy and incompetent. This is the reason nobody should ever use gaming as any kind of comparison or a benchmark. And it's definitely not a valid argument for Linux performance overall.