You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@arrow.apache.org by we...@apache.org on 2019/09/09 15:48:08 UTC

[arrow-site] branch master updated: ARROW-6419: [Website] Update Parquet perf results after reverting to jemalloc stable-4

This is an automated email from the ASF dual-hosted git repository.

wesm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/arrow-site.git


The following commit(s) were added to refs/heads/master by this push:
     new adcb1a3  ARROW-6419: [Website] Update Parquet perf results after reverting to jemalloc stable-4
adcb1a3 is described below

commit adcb1a3b8ff9f95e9089446d5b9e974551745c6d
Author: Wes McKinney <we...@users.noreply.github.com>
AuthorDate: Mon Sep 9 10:48:04 2019 -0500

    ARROW-6419: [Website] Update Parquet perf results after reverting to jemalloc stable-4
---
 _posts/2019-09-03-faster-strings-cpp-parquet.md |  10 +++++-----
 img/20190903_parquet_read_perf.png              | Bin 12490 -> 37197 bytes
 img/20190903_parquet_write_perf.png             | Bin 20846 -> 11605 bytes
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_posts/2019-09-03-faster-strings-cpp-parquet.md b/_posts/2019-09-03-faster-strings-cpp-parquet.md
index e0d0b5d..23293f5 100644
--- a/_posts/2019-09-03-faster-strings-cpp-parquet.md
+++ b/_posts/2019-09-03-faster-strings-cpp-parquet.md
@@ -196,11 +196,11 @@ Then, the reading benchmarks:
 
 Here, similarly reading `DictionaryArray` directly is many times faster.
 
-These benchmarks show that reading the dense binary data is slower in the
-master branch than in version 0.12.1, so we will need to do some profiling and
-see what we can do to bring read performance back in line. Optimizing the dense
-read path has not been too much of a priority relative to the dictionary read
-path in this work. See [ARROW-6417][12] for some investigation and discussion.
+These benchmarks show that parallel reads of dense binary data may be slightly
+slower though single-threaded reads are now faster. We may want to do some
+profiling and see what we can do to bring read performance back in
+line. Optimizing the dense read path has not been too much of a priority
+relative to the dictionary read path in this work.
 
 # Memory Use Improvements
 
diff --git a/img/20190903_parquet_read_perf.png b/img/20190903_parquet_read_perf.png
index d1b1fe8..fa4e4f5 100644
Binary files a/img/20190903_parquet_read_perf.png and b/img/20190903_parquet_read_perf.png differ
diff --git a/img/20190903_parquet_write_perf.png b/img/20190903_parquet_write_perf.png
index 4560607..2c91baf 100644
Binary files a/img/20190903_parquet_write_perf.png and b/img/20190903_parquet_write_perf.png differ