RAD Game's New Oodle Data Compression Beats Open-Source Alternatives

[bug77]

I have a hard time getting that excited about faster decompression speeds, although i'm sure it's important in places like mobile/embedded, or perhaps in datacenters. The compression speed and ratio are just much more important for my purposes. Decompression is never really a factor.

If you were dropbox or something similar, you'd be storing stuff one at upload time and decode it many, many times.
Even for your purposes, decompression is never really a factor, because it's almost always an order of magnitude faster than compression. But someone still has to keep an eye out to keep it that way.

Edit: In case of games, texture decompression speed is linked to level load times.

[DanglingPointer]

Would have been nice to see lrzip thrown into the mix! I've been using it as default in linux now. Compresses faster and creates smaller files than xz. Needs plenty of ram though.

[mlau]

Calling Rich's review "independent" is quite a stretch.
He has been advocating RAD products for several seasons, received access to advanced versions and source,
at a minimum, he qualifies as a good acquaintance. Link is maybe stronger, we don't know.
Unsurprisingly, his last statement looks like an undisguised advertisement.

I was about to note that Mr Geldreich seems very biased. He also seems to dislike open source and revel in
an opportunity to rub it in when a paid solution is better than a free one developed by hobbyists.

[log0]

I was about to note that Mr Geldreich seems very biased. He also seems to dislike open source and revel in
an opportunity to rub it in when a paid solution is better than a free one developed by hobbyists.

His own compression codec lzham is open source. Maybe this oodle codec is actually that good. Would be nice to see more independent benchmarks though.

[caligula]

You are talking about many different compression use cases like routers, Raspberry Pi, mobile, etc. But:
Rich Geldreich - former Valve developer... Now Valve it is mainly Steam digital distribution, but in the past it was game developer.
RAD Game Tools - like it is in the name - the most important usage of it is in game development.

Also consider that many, many PC games on starting screen has copyright information that it is using RAD/Blink technology... I think that there is some reason for that situation - perhaps it is about RAD better decompression rate than others tools, or... license/patents mess. When you buy RAD - probably you do not need to worry about layers...

Of course it's great for games, but Phoronix users aren't often gamers. There are Linux professionals here using totally different technology for different purposes.

[jntesteves]

richgel999 : I tried to tone down my comment, I hope it isn't offensive. I'm definitely not calling you a liar and actually agree with your conclusion. If you have been getting much disagreement, I think it might be because the post doesn't make it clear what kind of use case is been prioritized. Also, on your own previous post you proved that lz4hc is a better fit for offline compression, but here you use regular lz4 instead. Off course lz4 is included there mostly for reference purposes only as it's currently absolutely unfit for this use case, but neither zlib or zstd are fit for this use case either. Basically these new compressors by RAD don't have much competition nowadays, they only had to beat LZHAM, they ended up beating everything else too in the process.

The compression speed chart is the only one that bothers me a little, at what they are meant for, most of these shouldn't be slower than zlib, but then, that's not the use case been tested.

Thanks for your time testing all this and making it publicly available, it's certainly appreciated.

[ssokolow]

Zopflipng results in better compression than AdvanceCOMP. Do you have the same experience?

It's been a while since I tried Zopflipng and, at the time, I think I concluded that it compressed better but the return on investment wasn't worth it. (ie. the ratio gains for my types of images weren't worth the increased compression time)

I'll probably come back to it once I've got a web project hitting 1.0 and I expect to not change the selection and content of the images. (Either that, or I'll write some kind of build automation smart enough to know which PNGs have already been zopfli'd.)