Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use arrow row format in SortPreservingMerge ~50-70% faster #3386

Merged
merged 1 commit into from
Sep 27, 2022

Conversation

tustvold
Copy link
Contributor

@tustvold tustvold commented Sep 7, 2022

Which issue does this PR close?

Part of #416

Rationale for this change

merge i64               time:   [18.361 ms 18.383 ms 18.406 ms]                      
                        change: [-53.779% -53.520% -53.283%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) low mild
  1 (1.00%) high mild
  1 (1.00%) high severe

merge f64               time:   [18.271 ms 18.289 ms 18.307 ms]                      
                        change: [-53.881% -53.730% -53.598%] (p = 0.00 < 0.05)
                        Performance has improved.

merge utf8 low cardinality                                                                            
                        time:   [17.168 ms 17.185 ms 17.203 ms]
                        change: [-62.941% -62.831% -62.731%] (p = 0.00 < 0.05)
                        Performance has improved.

merge utf8 high cardinality                                                                            
                        time:   [19.513 ms 19.539 ms 19.566 ms]
                        change: [-54.113% -54.022% -53.932%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

merge utf8 tuple        time:   [27.579 ms 27.608 ms 27.639 ms]                             
                        change: [-56.213% -56.134% -56.054%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

merge utf8 dictionary   time:   [16.251 ms 16.265 ms 16.280 ms]                                  
                        change: [-65.210% -65.063% -64.945%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

merge utf8 dictionary tuple                                                                            
                        time:   [19.057 ms 19.081 ms 19.111 ms]
                        change: [-70.756% -70.581% -70.418%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  2 (2.00%) low mild
  1 (1.00%) high mild
  1 (1.00%) high severe

merge mixed utf8 dictionary tuple                                                                            
                        time:   [24.586 ms 24.634 ms 24.684 ms]
                        change: [-63.732% -63.583% -63.439%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

merge mixed tuple       time:   [27.034 ms 27.075 ms 27.119 ms]                              
                        change: [-47.178% -46.969% -46.762%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

It is also worth highlighting that these benchmarks are in many ways the worst case, as the rows are distributed randomly across streams, instead of large contiguous slices, which increases the cost of reassembly, i.e. the non-comparison portion of the operator.

What changes are included in this PR?

Are there any user-facing changes?

@tustvold tustvold changed the title Use arrow row format in SortPreservingMerge Use arrow row format in SortPreservingMerge ~50-70% faster Sep 7, 2022
@@ -321,10 +318,13 @@ pub(crate) struct SortPreservingMergeStream {
next_batch_id: usize,

/// min heap for record comparison
min_heap: BinaryHeap<SortKeyCursor>,
max_heap: BinaryHeap<Reverse<SortKeyCursor>>,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a somewhat amusing surprise, BinaryHeap is a max heap, not a min heap, the comparator for SortKeyCursor was just backwards.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But w/ Reverse, it's a "min heap" again, so I think the variable name should read min_heap.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a max heap of reversed elements no?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we get into philosophical discussions here, but IMHO the variable should describe the entire construct (BinaryHeap<Reverse<SortKeyCursor>>), not just the outer shell (BinaryHeap<...>).

Should you decide the keep the name, then at least adjust the docstring which still read min heap.

@github-actions github-actions bot added the core Core datafusion crate label Sep 7, 2022
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😍 where this is headed

// their batch_idx.
batch_comparators: RwLock<HashMap<usize, Vec<DynComparator>>>,
sort_options: Arc<Vec<SortOptions>>,
rows: Rows,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that certainly looks nicer

Copy link
Member

@yjshen yjshen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The speed-up is fantastic, love it!


let rows = self.row_converter.convert(&cols);

let cursor = SortKeyCursor::new(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to track the total memory used by all cursors since the cursor now holds Rows. We could do this as follow-ups but note here as it came to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that memory usage is a potential concern (as we are effectively copying data into the Rows format.

A follow on PR would be good I think. I filed #3609

@alamb alamb mentioned this pull request Sep 19, 2022
8 tasks
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


let rows = self.row_converter.convert(&cols);

let cursor = SortKeyCursor::new(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that memory usage is a potential concern (as we are effectively copying data into the Rows format.

A follow on PR would be good I think. I filed #3609

let _timer = elapsed_compute.timer();
// NB timer records time taken on drop, so there are no
// calls to `timer.done()` below.
let elapsed_compute = self.tracking_metrics.elapsed_compute().clone();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this simply reduces the overhead of timing , right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, which turned out to be a major bottleneck, as Instant::now is a syscall

@alamb alamb mentioned this pull request Sep 25, 2022
2 tasks
@alamb alamb merged commit 451e441 into apache:master Sep 27, 2022
@ursabot
Copy link

ursabot commented Sep 27, 2022

Benchmark runs are scheduled for baseline = 15c19c3 and contender = 451e441. 451e441 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

@Dandandan
Copy link
Contributor

Real nice 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core datafusion crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants