On Fri, Jun 15, 2012 at 1:21 PM, Olivier Lamy <[email protected]> wrote: > 2012/6/15 Tatu Saloranta <[email protected]>: >> On Thu, Jun 14, 2012 at 11:25 PM, Simone Tripodi >> <[email protected]> wrote: >>> Hi all guys, >> .. >>> >>> * We didn't think to apply a GZip compression - it is true that we >>> are working off-heap, but hopefully the allocated space can handle >>> more objects by compressing them >> >> Gzip is VERY CPU intensive, so maybe just say "support compression". >> LZF/Snappy/LZ4 are 4-6x faster to compress, 2-3x to uncompress, so >> they could be better choices here. >> So at least it would make sense to allow pluggable compression codecs. > +1 > Good idea about having a pluggable mechanism for this feature. > > I just ask myself if compression of a serialization of a object will > be a huge gain ? > At least for the server side using the plain/text (i.e. String) > transfer mode the factor can be high but for serialization of an > Object, I'm septic (but I agree don't have any figures :-) )
Hard to know, depends on what gets compressed (single entry, multiple, page/block) and so forth. The biggest gain would be if there's actual disk storage to slow disk (no SSD), as fast codecs can compress as fast or faster than disks can write, and uncompress faster. But it can also help by allowing bigger data sets to kept in working set. Anyway, it all depends, and very hard to say without trying things out. :) -+ Tatu +-
