Odpověď na názor

Hezký test, ještě mi tam chybí brotli, který už je dokonce podporován jako content-encoding v HTTP. Zstd podalo návrh myslím někdy na podzim minulý rok. Brotli má navíc slovník, který by měl iniciálně zvýhodňovat HTML dokumenty, takže srovnání je trochu nefér.

Gzip si stále ponechává výhodu v malé paměťové spotřebě. Pokud budu mít server s 10000 konexema, tak se zstd nebo brotli můžou docela prodražit. Gzip musel běžet v Dos na PC s 500kB reálně využitelné paměti.

Bzip2 je prakticky mrtvý už dlouho. Nejen kvůli pomalosti komprese vs poměru komprese, ale hlavně kvůli extrémní pomalosti dekomprese. Tím značně ztrácí u typického použití, kdy se jednou zabalí a potom mnohokrát rozbaluje. Ten výrazně lepší poměr u textových dat z osciloskopu mě docela překvapuje, viz dále.

Nebylo by od věci rozšířit vzorek dat, home a /usr budou předpokládám obsahovat množství binárních dat. Zstd i Brotli exceluje hlavně na textových datech. Matně si pamatuju svůj test na JSON (stovky MB), kde se Zstd dostal na 60% oproti Gzip a 110% oproti Xz. Bzip2 byl na 97% oproti Xz. Samozřejmě nesrovnatelné časy, i když Zstd nad cca 13 taky začně velmi zpomalovat.

Zajímavosti Zstd je, že nebyl brán ohled pouze na efektivitu algoritmu, ale i na jeho implementaci v současných CPU. Umožňuje tak snad paralelizovat instrukce v různých ALU. To možná vysvětluje jeho pomalejší běh na ARM, které nemusí mít tak dobrou schopnost paralelizace jako x86_64 (ale nejspíš bude záležet na generaci a orientaci).