Uh oh!
There was an error while loading. Please reload this page.
[SPARK-16526][SQL] Benchmarking Performance for Fast HashMap Implementations - #14266
[SPARK-16526][SQL] Benchmarking Performance for Fast HashMap Implementations#14266ooq wants to merge 4 commits into
Conversation
SparkQA
commented
Jul 19, 2016
Test build #62539 has finished for PR 14266 at commit
|
SparkQA
commented
Jul 19, 2016
Test build #62541 has finished for PR 14266 at commit
|
SparkQA
commented
Jul 27, 2016
Test build #62945 has finished for PR 14266 at commit
|
SparkQA
commented
Jul 28, 2016
Test build #62947 has finished for PR 14266 at commit
|
| sparkSession.conf.set("spark.sql.codegen.aggregate.map.columns.max", "30") | ||
| // scalastyle:off | ||
| println(Benchmark.getJVMOSInfo()) |
There was a problem hiding this comment.
nit: to minimize duplication, maybe create a small utility function that can then be reused in all test cases.
sameeragarwal
commented
Aug 1, 2016
Just a minor nit. LGTM. |
| */ | ||
| } | ||
| ignore("varying key fields, varying value field, 16 linear distinct keys") { |
There was a problem hiding this comment.
The performance difference between column-based and row-based are cache locality, could you increase the number of distinct keys to make sure that not all the keys/values are fit in L1 cache? for example, 4k. We could also increase that to 64k in first two cases (single key, single value).
ooq
commented
Aug 5, 2016
@davies Added some test results with larger number of distinct keys. |
SparkQA
commented
Aug 5, 2016
Test build #63296 has finished for PR 14266 at commit
|
SparkQA
commented
Aug 6, 2016
Test build #63299 has finished for PR 14266 at commit
|
| */ | ||
| } | ||
| ignore("single key field, single value field, varying linear distinct keys") { |
There was a problem hiding this comment.
Should we access them in random way?
HyukjinKwon
commented
Feb 9, 2017
(gentle ping @ooq) |
## What changes were proposed in this pull request? This PR proposes to close stale PRs. What I mean by "stale" here includes that there are some review comments by reviewers but the author looks inactive without any answer to them more than a month. I left some comments roughly a week ago to ping and the author looks still inactive in these PR below These below includes some PR suggested to be closed and a PR against another branch which seems obviously inappropriate. Given the comments in the last three PRs below, they are probably worth being taken over by anyone who is interested in it. Closesapache#7963Closesapache#8374Closesapache#11192Closesapache#11374Closesapache#11692Closesapache#12243Closesapache#12583Closesapache#12620Closesapache#12675Closesapache#12697Closesapache#12800Closesapache#13715Closesapache#14266Closesapache#15053Closesapache#15159Closesapache#15209Closesapache#15264Closesapache#15267Closesapache#15871Closesapache#15861Closesapache#16319Closesapache#16324Closesapache#16890Closesapache#12398Closesapache#12933Closesapache#14517 ## How was this patch tested? N/A Author: hyukjinkwon <gurwls223@gmail.com> Closesapache#16937 from HyukjinKwon/stale-prs-close.
What changes were proposed in this pull request?
The 3rd PR in its series to resolve SPARK-16523.
This patch adds benchmark tests for vectorized hashmap vs. row-based hashmap (along with results in the comments). Those tests are ignored by default as they take long to run.
How was this patch tested?
This patch are mostly tests itself.