2 ms·
They are testing compression on a 6849 byte file full of English text. (GPL) This is a terrible comparison test - first of all, it's biased because of Brotli's
by joosters 11y ago
They are testing compression on a 6849 byte file full of English text. (GPL)
This is a terrible comparison test - first of all, it's biased because of Brotli's built-in dictionary, and the file size is so small that the compression performance might well be overwhelmed by the startup time of each compressor / decompressor. Consider that the compression level of bzip2 (the 1-9 parameter) controls a search block size of 100k-900k - so the input file is far far smaller than even the smallest, worst compression setting.
There are several good example file sets to try compression with, they should be used if you want to do any kind of comparative general testing.
- kijin 11y agoThe article explicitly states that it is trying to find out which algorithm is optimal for small text-based documents that are common on the web, such as CSS, JS, and HTML. The best compression algorithm for small text files might be very different from the best algorithm for large amounts of general data. If your browser needs to decompress 100 separate files in a fraction of a second, startup time does matter.
- joosters 11y agoFair enough, but if you want to compress CSS, JS and HTML then why not test it on those? It also depends upon how you are supplying the compressed data. For static files, the compression time might not even matter - the web server can cache all the compressed versions and the compression performance is minimised. For dynamic data (e.g. the output of a PHP or whatever), you might also want to test how well the compressors handle streaming data, e.g. feeding parts of a page piecemeal into the compressor and directly sending the output to the client packet by packet. Some compression systems handle this extremely badly.