[
https://issues.apache.org/jira/browse/GEODE-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Boorlagadda updated GEODE-1573:
-----------------------------------
Component/s: docs
> Use snappy java implementation
> ------------------------------
>
> Key: GEODE-1573
> URL: https://issues.apache.org/jira/browse/GEODE-1573
> Project: Geode
> Issue Type: Improvement
> Components: docs, regions
> Reporter: Sai Boorlagadda
> Assignee: Sai Boorlagadda
>
> Geode currently bundles xerial/snappy as a default implementation. And this
> is a "JNI wrapper" on google 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 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 break compatibility, as Geode
> does not save compressed data to disk or send on the wire.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
