"time tar cvzf local-revert.tgz local" This would not negate the point but possibly make the delta even larger, but you have to be careful when benchmarking ta

"time tar cvzf local-revert.tgz local" This would not negate the point but possibly make the delta even larger, but you have to be careful when benchmarking tar with the "v" flag. The time to print ~400,000 lines out to the terminal can be nontrivial! It may even be the majority of the time for the pure tar case. Like I said, this won't negate the point but amplify it; subtract an approximately constant time from both times and the multiplicative delta between them will grow. (Some modern shells that focus on handling lots of text very quickly may be less impacted than some older-style shells.) In the interests of not making another tiny post, I also endorse the use of parallel compression for the benchmark too, which will close the gap somewhat. You also want to consider the overall use case and the overall bandwidth you have to the final destination. If I were trying to upload something over my home network connection to some remote source, I can afford almost any parallel compression scheme there is because it's a pure win if I can end up sending fewer bytes. Compression is better-than-free in that case. On the flip side, if you don't care about disk usage it's hard to do very much compression at NVMe SSD speeds. (There are some things that may be able to do it, but you won't get much.)