An interesting angle that I read a paper on in grad school a few years ago but don't have handy: because of the asymmetric growth of CPU speed vs. hard drive speed, you can actually get performance gains by enabling filesystem compression. It seems counter-intuitive, but it boils down to "can I compress this data faster than the disk can write it?"
If you're blasting highly compressible data to disk, compressing it on the fly can, in some circumstances, have a net bandwidth greater than just writing the data to disk (and greater than the disk alone is capable of). Yes, you incur more CPU load, but it's a net win. It's not universally true, YMMV etc.
One counter to this argument is that, while the CPU has thousands of cycles to do compression while an old 5400 RPM spinning rust drive seeks or writes, a modern SSD like the new Samsung 960 Pro can write data at 2100 MB/s, giving the CPU perhaps one cycle per byte, which makes compression difficult.
The counter to my counter, of course, is that specialized silicon for compression can easily keep up with even these speeds. In fact, Sandforce SSD controllers build in compression to boost read and write speeds!
Thanks for the reminder that while grad school doesn't feel that long ago, spinning rust was definitely the name of the game at the time. SSDs were a thing, but way too expensive and small for non-exotic purposes... :D
Sandforce does compression for minimizing writes, not for speed. They are slower than non-compressing controllers for some tasks because of that, but it should increase the device's lifetime.
I can say that's true from empirical experience - doubly so if you're targeting an environment where the data's likely to be stored on a NAS or some other fairly slow storage.
(And yeah, natch, insert recitation of the Liturgy of the Optimizer as a charm against the appearance of a certain Knuth quote.)
Slowdown in one set of tasks and speed-up in another. For example, boot time is usually shorter when system folders are compressed (with compact /CompactOS:always).
> For example, boot time is usually shorter when system folders are compressed
Reads, in general, will be "boosted" when the filesystem is compressed.
You get an (almost) free boost by reading and extracting compressed data on the fly into memory/cpu. ie. read 4mb's off the disk but it expands to 8mb's (or more!) in memory, so read performance is elevated.
Writing of course, is slowed.
For some server loads, disk compression still makes a lot of sense - making the claim "We live in a post-file-system-compression world" a little dubious.
I think a cpu can compress data (provided it's in memory) orders of magnitude faster than it can write to disk. Now that I think about it though, the context would be necessary to compress well, so maybe you would need to read surrounding data.
Compress any larger piece of data on your own computer, and watch the CPU bottleneck.
Even on the fastest CPU's, writing a file that must be compressed first, will always be slower than the same file on the same hardware, but not being compressed before written to disk.
It may not be magnitudes slower - depending on the data, hardware, and algorithm, of course - but it will incur some write penalty. So, with disk compression, you get a write penalty and a read boost.
You are correct that most compression algorithms are slower than their corresponding decompression, which means the writes tend to be a different tradeoff than the reads.
I do not agree with your statement that compress + write is always slower, though. The analysis for cost/benefit of compression is the exact same logic for both reads and writes, but with different formulas based on how fast you can compress/decompress and read/write blocks. Let's imagine that your disk takes 10ms to write 64KB and 20ms to write 256KB. Then if compression of a 256KB block down to 64KB takes 5ms, writing is faster with compression done first. On the other hand, if compressing it takes 50ms, then writing it raw is quicker.
Whether it's a penalty or boost for reading or writing is entirely dependent on the performance characteristics of reading, writing, compressing, and decompressing. I can think of a reducto ad absurdum that's a write boost and a read penalty - I/O is carving and reading text from a stone tablet, compression is looking up shorthand from a dictionary.
I don't understand how that is technologically possible.
Most of Windows 10's boot, when Fast Startup is enabled, doesn't involve the typical system folders at all. Effectively when you shut down, they collapse the userspace, and store the kernel/services/etc into the hibernation file. When you "boot" the computer, the hibernation file is re-mapped into memory sequentially, and the user is prompted to login.
Compacting the OS definitely saves space. But I don't understand how it would reduce boot times from a technical perspective, since IO isn't even reading those folders during a default boot on Windows 10.
You're not always "fast booting" windows 10. When you restart/reboot, for example, it must read all those files from the disk.
You'll get a performance boost by reading compressed data off the (slow) disk and expanding it in (fast) memory.
This can effectively increase read speeds greatly (reading a 2mb file off disk but it expands to 3mb's for example, that 3rd mb came almost "for free").
Any version of Windows after I think XP kind of does defragging automatically. At least to the point where the user is told it isn't necessary to do manually.
When NTFS was first released Microsoft claimed it was so awesome it didn't need defragging. In later releases of Windows NT they added a defragger. By around the time of XP this was automatically scheduled to run in the background.
tldr: NTFS does a better job of avoiding fragmentation than FAT, but both need defragging.
