You're right about the broken links, my bad.
The first link related to a few statements by Mark Ruijter, copy/pasted below :
I just looked into it and it appears to be promising.
On average the speeds appear to be 48% faster then snappy.
This is amazing since snappy has proved to be 30%
On Tue, Feb 14, 2012 at 1:47 PM, Hugo Chevrain hugochevr...@gmail.com wrote:
Are you sure about these figures ? the difference seems too large. It's
almost
unbelievable.
--
You should not,
Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/?
p=688) and there is also
The second link is broken, just remove scribe. from it.
https://twitter.com/#!/otisg/status/148848850914902016
It causes a cross-domain error, not sure why he could see it though.
On Wednesday, February 15, 2012 9:23:37 AM, Kok, Auke-jan H wrote:
On Tue, Feb 14, 2012 at 1:47 PM, Hugo
Silesia corpus (avg of 10 runs), AMD bulldozer box, 12G ram, 1Ghz cpu:
lz4 = 739860 us ( 286 MB/s) 195930 us (1081 MB/s) 211957760
- 101630873 47.9%
snappy 1.0.4 = 1050 ms ( 201 MB/s) 248 ms ( 853 MB/s) 211957760
- 104739310 49.4%
snappy-c = 940111
Markus Lindberg marcuslindb...@gmail.com writes:
Are you sure about these figures ? the difference seems too large. It's almost
unbelievable.
Yes, my benchmarks totally disagree with them. In my tests lz4 is
generally slower than snappy-c.
-Andi
--
a...@linux.intel.com -- Speaking for
Are you sure about these figures ? the difference seems too large. It's
almost
unbelievable.
--
You should not,
Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/?
p=688) and there is also such finding into an Hadoop thread
Hi,
so here it is, LZ4 compression method inside btrfs. The patchset is based on
top of current Chris' for-linus + Andi's snappy implementation + the fixes from
Li Zefan. Passes xfstests and stresstests.
I haven't measured performance on wide range of hardware or workloads, rather
wanted to
