Thiago Macieira wrote:
> More importantly, the decompression times: gzip took 0.84s, zstd 0.30s and xz > 2.81s. But bzip2 needed 6.6s. I cannot reproduce those relative performance figures on neither of my machines. On a 95Mb directory I'm getting on my Mac (tar -c dir | $compressor $opts > /dev/null): xz -c6: 40.2s (100%) xz -c6 --threads=4: 16.3s (362%) bzip2 -9: 10.3s (100%) pbzip2 -9: 5s (392%) Similar relative figures on my much slower Linux machine. Interestingly parallelisation incurs about a 50% overhead on Mac. Also, pxz/xz --threads=N doesn't always give a performance gain, either because of the input size I'm testing with, or because I'm compressing stdin. I don't really want to spend more time figuring that out. > negligible < significant < considerable Nope, something can be highly significant but perfectly negligible. > I'm claiming that the size is less than what you claim to be a problem. Who said anything about problems? I'm talking about trade-offs. > That's why you should strip them out and compress them. Store them where you > may need them (possibly never). I need to be able to get useful post-mortem backtraces, and typically don't want to have to figure out which debug information to get back online and how. That's part of the trade-off. On my faster/bigger system I build all of Qt with embedded debug info, elsewhere I only add debug info to QtBase. R. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
