HexaPDF produced the smallest PDF in two cases and was second in the other four cases where smpdf was the best compressor. HexaPDF in CSP mode and smpdf can be considered equal because of the margin differences in file sizes.

When page compression is activated, HexaPDF is much slower when processing big content streams but this is expected.

HexaPDF is only up to 2.5x slower than pdftk which was the fastest (except for the a.pdf file) when page compression is not activated. This is rather good considering HexaPDF is written in Ruby while pdftk is a compiled binary.

Memory usage has been significantly reduced by not applying stream filters where possible. In the best possible case HexaPDF now just copies the data from the input IO directly to the output IO. This can be seen in the case of the non-compacting hexapdf script for file e.pdf, going from originally ~140MB to ~40MB!

In all cases HexaPDF uses much less memory than the other Ruby based solutions.

The a.pdf test case uses a very small file, so the initial startup time for the Ruby VM together with loading Rubygems is a big part of the overall runtime.

The f.pdf test case uses a very big file. Therefore HexaPDF in CSP mode, origami, combine_pdf and smpdf were killed after about 2 minutes since they would have taken a long time to finish.

Overall HexaPDF fares quite well in the benchmark in terms of speed and memory use!