Performance advantage over pako might not be true for inflateSync?

[basro]

The readme on this project claims up to 40% faster performance than pako but this doesn't seem to hold true in the inflateSync category (on the browser).

This benchmark compares fflate.inflateSync vs pako.inflateRaw (which I believe are equivalent in functionality)

https://benchmarklab.azurewebsites.net/Benchmarks/Show/35610/0/deflate---pako-vs-fflate

In my system pako is winning by a big margin in all cases.

I'd be happy to be corrected if the benchmark is flawed somehow, I really wanted to use this lib if it was faster than pako.

Otherwise I think the readme is misleading and should be amended.

_{*Edit: I realized that comparing deflate might not be appropiate since they might be producing different results, however my point is still valid for inflate so I've changed this post to focus on it.}

[101arrowz]

Pako has had a new major version since the last time I updated the performance comparison; it's likely that Pako is faster than it used to be. That said, the link you've provided is really not a good test of compression performance; the data being compressed is either a single string repeated thousands of times or an repeating sequence of 0...255. Both of these aren't realistic compression workloads and are also very easy to "performance hack" for. If you'd like to make a more robust performance comparison, please use the files in fflate's test suite, or your own non-contrived workloads (e.g. some JS blob or something). I'll try to investigate the performance characteristics of modern Pako vs. fflate over the next few days myself as well. Thanks for the report!

[basro]

Thanks for your reply,
While this bench is using modern pako, I first noticed the performance difference against pako ver 0.1.1 (which is what a project of mine had been using).

[101arrowz]

That is a surprising result then - do you have any sample files from that project I could use to make a performance comparison for your specific workload? When I tested older versions of Pako it was unilaterally slower on all realistic kinds of data I tried (though Pako could be faster for contrived data like this)

[basro]

I've forked the benchmark to compare against pako 0.1.1, it goes about the same on my system.
https://benchmarklab.azurewebsites.net/Benchmarks/Show/35611/0/deflate---pako-011-vs-fflate

Sorry, so far I've only tested with artificial inputs like in the benchmark, one not included in the benchmark site was a 2MB file made out of random bytes between 0 and 100, pako also won there.

[101arrowz]

FWIW on that link on my machine, fflate is much faster for deflate and much slower for inflate. But again, I wouldn't put too much stock into that result because the data is artificial.

Random bytes are generally incompressible and are thus also not something that fflate aims to be fast at handling. I just ran tests locally on my machine using the "realistic data" in my test suite (see the test/ subdirectory of the repo). The performance comparison gives results that are between 20-30% faster for fflate than Pako for decompression (inflate) and 30-40% faster for compression (deflate). These are less extreme than when I last tried, possibly because I'm using a different machine or a newer Node runtime or many other possible reasons - but fflate is still definitely faster

If you have specific realistic data showing better performance with Pako, feel free to send it over. However, the synthetic benchmarks you've sent so far don't seem to line up with what I see on realistic data.

[basro]

There's something more that is quite odd however: Benchmarking the same artificial data but with gunzipSync instead of inflateSync gives the edge to fflate:

https://benchmarklab.azurewebsites.net/Benchmarks/Show/26303/0/gzip-compatible-compression-libraries-comparison---pako

(This is the original benchmark which I found online and modified to compare inflate instead of gunzip)

I had expected gzip's deflate to be the dominant factor in the benchmark and it confuses me that they have different results.

FWIW on that link on my machine, fflate is much faster for deflate and much slower for inflate. But again, I wouldn't put too much stock into that result because the data is artificial.

Yeah, It seems on my system on chrome I get those results too, on firefox both deflate and inflate are slower.

I'll update the web benchmarks using your tests files and get back to you.

[basro]

I've implemented the web bench using one of the files you use in your tests:

https://benchmarklab.azurewebsites.net/Benchmarks/Show/35612/9/deflate---pako-vs-fflate---realistic

In this bench fflate inflate continues to be slower than pako for me.

[101arrowz]

Thanks, I can see that Pako is faster here. I'll look into this within the next few days!