Re: Best Compression Algorithm


<Industrial.One01@xxxxxxxxx> wrote in message
news:1175087307.507290.54190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I think Arithmatic coding provides the best compression ratio (but
slow as hell)


well, faster than arithmetic is very much possible, but for many generic
compressors, it may now be fast enough to be justified (for example, in
large-file compressors, where the fact that encode/decode is a little slower
than ideal is no big worry).

however, in my case I prefer speed and tunability over raw compression, so I
tend to prefer algos similar to that of deflate.


as a general rule, huffman is not all that much worse than arithmetic (I
feel it only really matters much when one is sitting around trying to tune
things for slightly better ratios), and huffman is enough faster, that
personally I feel it makes more sense a lot of the time (when speed is what
is important, which is generally the rule in my case).


of note is that a poorly written huffman coder is still very much slower
than a well written arithmetic coder.


many also want compression though, size is their priority. after all, people
still use bzip2 even though it is slower than gzip, and people use winrar
and 7zip as well, even if plain zip is faster.


so, it depends, if one wants to compress some big file for sending over a
damn slow link (aka: the net), ratio matters, so everything even vaguely
reasonable makes sense. if you just want to in-place compress some app data
so it takes less space on the users' HD, faster is better (larger or smaller
doesn't matter as much in this case, but the user likely doesn't want to
wait extra time for the app to de/compress its various datafiles for only
meager savings in total used HD space).


or such...


.