some other funny benchmark numbers:
i wondered how performance/compressratio of lzjb,lzo and gzip would compare if
we have optimal compressible datastream.
since zfs handles repeating zero`s quite efficiently (i.e. allocating no space)
i tried writing non-zero values.
the result is quite
On 6/30/07, roland [EMAIL PROTECTED] wrote:
some other funny benchmark numbers:
i wondered how performance/compressratio of lzjb,lzo and gzip would compare if
we have optimal compressible datastream.
since zfs handles repeating zero`s quite efficiently (i.e. allocating no space)
i tried
Those are interesting results. Does this mean you've already written lzo
support into ZFS? If not, that would be a great next step -- licensing
issues can be sorted out later...
Adam
On Sat, Jun 16, 2007 at 04:40:48AM -0700, roland wrote:
btw - is there some way to directly compare lzjb vs lzo
For what it's worth, at a previous job I actually ported LZO to an
OpenFirmware
implementation. It's very small, doesn't rely on the standard libraries, and
would be
trivial to get running in a kernel. (Licensing might be an issue, of course.)
just for my personal interest - are you speaking
btw - is there some way to directly compare lzjb vs lzo compression - to see
which performs better and using less cpu ?
here those numbers from my little benchmark:
|lzo |6m39.603s |2.99x
|gzip |7m46.875s |3.41x
|lzjb |7m7.600s |1.79x
i`m just curious about these numbers - with lzo i got
Hi roland,
roland [EMAIL PROTECTED] wrote:
btw - is there some way to directly compare lzjb vs lzo compression -
to see which performs better and using less cpu ?
here those numbers from my little benchmark:
|lzo |6m39.603s |2.99x
|gzip |7m46.875s |3.41x
|lzjb |7m7.600s |1.79x
and
