Compression levels and the cost of a smaller archive

The June DevZIP overhaul made the size-versus-time choice more explicit. The engine and Windows interface gained compression levels, with a best-of-N backend selecting the smallest result for each solid group and recording the winning codec for extraction.

The levels could use different pools of codecs and transforms. Content-aware work included lossless JPEG reconstruction through Brunsli and a more expensive PNG path using preflate at the higher level. This wasn't simply turning one general compression setting further to the right.

On the recorded 97.41 MB per-category sweep, the default balanced result totaled about 47.98 MB, compared with 54.32 MB for the 7-Zip LZMA2 baseline. Max reached about 44.56 MB. Those correspond to roughly 11.7 and 18 percent smaller on that particular sweep.

The time cost was substantial. The same table totals about 275 seconds for balanced and 574 for max, against 12.5 seconds for the baseline. That is why the smaller max result shouldn't be described as the default's performance, or as a good tradeoff for every archive job.

The records describe byte-exact round trips for the reported DevZIP outputs. They also show competitors ahead on individual code and executable corpora, even where DevZIP won the aggregate. The earlier April mixed-large run used a different dataset, so its percentage isn't directly comparable to this sweep.

For me, the useful progress is the ability to make the tradeoff deliberately. If storage size matters most, there is a path to try; if turnaround time matters, use a faster level. The next codec work would explore improving the compression pool while keeping the archive readable and its reconstruction verifiable.