6 ms·
It's never been worth using due to the slowdown and fragmentation it causes.
by rexicus 10y ago
It's never been worth using due to the slowdown and fragmentation it causes.
- anonymfus 10y agoSlowdown 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).
- Alupis 10y ago> 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.
- foota 10y agoWhy is writing slowed?
- Alupis 10y agoBecause it must be compressed first, a cpu intensive task, which slows the already slow disk I/O.
- foota 10y agoI 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.
- Alupis 10y agoCompress 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.
- cmurphycode 10y agoYou 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.
- ThrustVectoring 10y agoWhether 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.
- Someone1234 10y agoI 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.
- Alupis 10y agoYou'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").
- anonymfus 10y ago>Most of Windows 10's boot, when Fast Startup is enabled[...] You are completely right for this case.
- Someone1234 10y agoThis case is the default for Windows 10.
- blahyawnblah 10y agoAny 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.
- rplst8 10y agoI think this was a feature of NTFS over FAT32 - not an OS level feature. XP was the first home oriented OS to support NTFS natively.
- brassic 10y agoWhen 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.
- tonyarkles 10y agoAn 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.
- bunderbunder 10y agoI 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.)
- LeifCarrotson 10y agoOne 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!
- miahi 10y agoSandforce 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.
- tonyarkles 10y agoThanks 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