Ik nam aan dat de winst die ze alsnog behalen met DEFLATE kwam door de entropy coding. LZ4 doet alleen sliding window compression, DEFLATE doet sliding window compression gevolgd door entropy coding. Daarom suggereerde ik dat LZ4 redundant is als je erna toch DEFLATE doet, maar andersom is dat natuurlijk niet zo.
Sowieso is compressie-algoritmen stacken meestal geen goed idee; LZ4 is niet ontworpen om nog gevolgd te worden door entropy coding. De manier waarop het resultaat van de sliding window compression in bytes gepackt wordt lijkt me ongunstig voor DEFLATE, terwijl in DEFLATE zelf de entropy coder juist zo gebouwd is dat 'ie de specifieke uitvoer van de sliding window compressie efficiënt kan coden.
Het zou me dus niets verbazen als DEFLATE alleen beter comprimeert dan LZ4 gevolgd door DEFLATE (zonder dat het veel trager wordt).
(Overigens zag ik dat LZ4 een sliding window van 64KB gebruikt; dat is groter dan de 32KB van DEFLATE, dus misschien dat dat helpt, of dat de data zó redundant dat twee keer comprimeren winst oplevert. Maar dat zou ik dus graag gekwantificeerd zien, anders is het moeilijk in te schatten of die extra complexiteit de moeite waard is.)
Waarschijnlijk belanden ze op een gegeven moment ook in het land van deminishing returns, de final data die ze nu aanbieden is al een stuk minder dan 1 MB.
Dat klopt, feitelijk leverde het switchen naar het binary formaat al de grootste winst op (zowel qua tijd als qua ruimte), vandaar dat ik me afvroeg in hoeverre die andere coderingen nog te rechtvaardigen waren...
In GCC heb je daarvoor __builtin_unreachable().