3 ms·
if it's faster for both compression and decompression it just seems better period? why do you say "if we mostly don't care about CPU usage"? being faster means
by dataangel 4y ago
if it's faster for both compression and decompression it just seems better period? why do you say "if we mostly don't care about CPU usage"? being faster means less CPU usage...
- deepsun 4y agoI said it's significantly _slower_, not faster, for compression.
- metadat 4y agoMinor nit: I too was confused by the wording: "compression speed is lower" To me this reads as though it's faster. Maybe you meant "compression speed is Slower"? Disclaimer: I generally dislike being pedantic, especially on HN. I hope this message doesn't come across that way.
- darrenf 4y agoIf compression speed is lower, then it's slower. If compression time is lower, then it's faster.
- kordlessagain 4y agoFaster/slower aside, it doesn't matter if it is slower to compress, because you only do that once for most use cases (thinking of downloadable repos or document stores). Decompression happens much more frequently. So, one compression algo that takes a lot of work (and time) to compress but uncompresses with less work than anything else is desirable because of the fact you only need compress once. So, less compute is required. There could be some use cases where this doesn't work out, such as a compressed network connection, where everything has to be compressed/decompressed in a 1:1 ratio.