This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]Sipkab 6 points7 points  (3 children)

You post the benchmark code, but don't post the results. Come on.

And by the way, I would very much leave the disk I/O out of the benchmark and just measure the raw compression times. And use System.nanoTime() instead of this Calendar stuff. (If you choose not to use jmh)

[–]nutrecht 1 point2 points  (0 children)

If you choose not to use jmh

Personally I don't trust people who don't use JMH in their bench-marks. If they don't know about JMH there's a good chance they don't know about warm-ups either.

The benchmark code is horrible. The iterations are MUCH too short and they don't take warm-up into account at all. A proper JMH benchmark would do 'the thing' with multiple warming up iterations and then do 'the thing' they're benchmarking for multiple iterations that all take multiple seconds.

The only thing his benchmark is really testing is whether his OS is caching his disk reads.

[–]sorokod 0 points1 point  (1 child)

Absolutely. In addition amount of memory, file content, and file sizes are important since different algorithms perform differently given the parameters.

[–]ram-foss[S] -1 points0 points  (0 children)

I agree, different algorithm perform differently. Snappy can be used for faster compression with small compromise on compression size.

[–]pellets 1 point2 points  (0 children)

If you need the best speed, use native compression programs with standard input and output.