geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sai Boorlagadda (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-1573) Use snappy java implementation
Date Thu, 23 Jun 2016 19:19:16 GMT

     [ https://issues.apache.org/jira/browse/GEODE-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sai Boorlagadda updated GEODE-1573:
-----------------------------------
    Description: 
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.

  was:
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 impact any existing users, as Geode does not save compressed data
to disk or on to the wire.


> 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)

Mime
View raw message