Geode currently bundles xerial/snappy
<https://github.com/xerial/snappy-java> as a default implementation. And
this is a "JNI wrapper" on google snappy <http://google.github.io/snappy/>
implementation.

"xerial/snappy" jar bundles several pre-compiled static libraries to
support various OS (linux, windows, SunOS) and architectures (x86, Sparc
etc). The current dependency (1.1.1.6) does not support SunOS (Sparc), so
the plan is to upgrade to a more recent version.

While upgrading to a more recent version, I found a pure java port
<https://github.com/dain/snappy> of original C++ implementation and wanted
to swap with use pure java implementation to avoid any platform specific
dependency on Geode.

>From the creator - "*the pure Java port is 20-30% faster for block
compress, 0-10% slower for block uncompress, and 0-5% slower for round-trip
block compression.*".

Though native version is better on uncompress (more number of gets, puts
depending on use cases), I would still vote for distributing with a pure
java version as a "default" implementation as Geode already exposes an
interface to allow any one to provide any custom implementation.

In case if there are any differences between these two implementations,
swapping with a pure java version should not impact any existing users, as
Geode does not save compressed data to disk or on to the wire.

Let me know if any one has different thoughts?

Sai

Reply via email to