Announcement

Collapse
No announcement yet.

New Compression Codecs Risk Making Zlib Obsolete

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    My test data was plain English text, 768 bytes of it. The small size of it probably contributes. I used the highest levels of each, lzo1x-999 and lz5hc-16. For my results see https://github.com/clbr/nes/blob/mas...ession/results

    Comment


    • #32
      Originally posted by milkylainen View Post
      I don't think zlib will be obsolete anytime soon either.
      It is well established, implemented and vetted code. Gains are still minor and not without trade-offs.
      I think the author forgets why something becomes a standard.
      CDs, mp3s etc are not the pinnacle of technology by any means yet they managed to become their respective technology standard for a very long time.
      Every time a competitor came along it was shot down because the standard had become ubiquitous and the competing ones did not offer any noticeable advantages to the average user on the receiving end.
      In this case it is the developers that are mostly on the receiving end. Do most developers really care about compression algorithm as long as it is well rounded and has decent performance? It is just another library with another function. Of course, some will. But calling zlib soon to be obsolete...

      It is hard to appreciate just how ubiquitous zlib really is.
      A lot of protocols, data compressions, boot compressions, stream compressions etc. Just about everything, everywhere relies on zlib. It is not going away anytime soon.
      zlib is used in lots of places, and many of those places are quite susceptible to its replacement.
      Google is obviously pushing brotli to replace it in the web space. MS and Apple will probably go along because, WTF not?
      WIthin a particular app's private usage (eg compressing assets for the use of a program) replacement depends simply on how easy the replacement is. Apple have provided libraries for iOS/OSX that offer the exact same API as zlib, but give either faster performance at zlib compression levels, or better compression at zlib performance levels (and they're likely to hardware accelerate this at some point). So it makes sense for those Apple developers to replace zlib. MS may well do the same. etc etc
      Standards that rely on network effects can persist forever; but if someone who (substantially) controls the network wants to force a change (Google; Apple) AND if the change is basically cost free, the situation is extremely different from something like mp3's. (And even there, of course, there is a substantial fraction of the world using a newer spec, namely AAC.)

      Comment

      Working...
      X