Uh oh!
There was an error while loading. Please reload this page.
[SPARK-12388] change default compression to lz4 - #10342
Conversation
rxin
commented
Dec 17, 2015
We also need to update the documentation, don't we? |
JoshRosen
commented
Dec 17, 2015
Note that LZ4 does not support concatenation of serialized streams, meaning that sort-based shuffle won't be able to take advantage of a special spill-merging optimization. This might not make a huge difference in practice compared to the other speed benefits of LZ4. |
SparkQA
commented
Dec 17, 2015
Test build #47876 has finished for PR 10342 at commit
|
nongli
commented
Dec 17, 2015
@JoshRosen Can you explain that some more? What are we giving up? Would fixing it if we decide to just to add a simple header that consisted of the lengths of each stream? |
rxin
commented
Dec 17, 2015
I think the main thing this is giving up is that previously we could use file channel's transferTo to copy data directly, but only when the compression blocks can be just concatenated at the byte level. Without that property, we'd have to read them (decompress) and then write them out again. |
davies
commented
Dec 17, 2015
I had patched LZ4BlockInputStream to support concated streams. |
SparkQA
commented
Dec 17, 2015
Test build #47898 has finished for PR 10342 at commit
|
SparkQA
commented
Dec 17, 2015
Test build #47908 has finished for PR 10342 at commit
|
There was a problem hiding this comment.
Can you comment what is modified? This is otherwise hard to review/maintain if lz4 updates.
There was a problem hiding this comment.
See the changes here: davies/lz4-java@cc1fa94
SparkQA
commented
Dec 18, 2015
Test build #47961 has finished for PR 10342 at commit
|
SparkQA
commented
Dec 18, 2015
Test build #2231 has finished for PR 10342 at commit
|
davies
commented
Dec 18, 2015
nongli
commented
Dec 21, 2015
LGTM |
rxin
commented
Oct 10, 2016
One thing I noticed when I was reviewing another pr just now: in the future we should also include test cases when pulling in 3rd party code. Otherwise it's pretty difficult to ensure correctness if we need to change the file. |
According the benchmark [1], LZ4-java could be 80% (or 30%) faster than Snappy.
After changing the compressor to LZ4, I saw 20% improvement on end-to-end time for a TPCDS query (Q4).
[1] https://github.com/ning/jvm-compressor-benchmark/wiki
cc @rxin