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

Allow specialized implementations to produce hints for the array adapter #3765

Merged
merged 1 commit into from
Oct 11, 2022

Conversation

isidentical
Copy link
Contributor

@isidentical isidentical commented Oct 7, 2022

Which issue does this PR close?

Closes #3762.

Rationale for this change

More details on #3762, but simply this allows us to instruct array/scalar function adapter to skip padding some arguments since the specialized version of functions don't need them.

What changes are included in this PR?

A new make_scalar_function_with_hints API (not public) that can take a list of hints and then map them to corresponding arguments and use it to decide whether they need padding or not.

This PR also provides usage of the new hints API, which in turn can speed-up regex_replace up to 1.3x.

Are there any user-facing changes?

No, this is a new API / optimization that can provide up to %25 speed-up.

@github-actions github-actions bot added the physical-expr Physical Expressions label Oct 7, 2022
@isidentical isidentical marked this pull request as ready for review October 7, 2022 22:48
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.

Makes sense to me -- thank you @isidentical

I wonder if you have any benchmark results that show this pattern improving performance?

datafusion/physical-expr/src/functions.rs Show resolved Hide resolved
/// - (default) `false`: indicates the argument needs to be padded if it is scalar
/// - `true`: indicates the argument can be converted to an array of length 1
///
pub(crate) fn make_scalar_function_with_hints<F>(
Copy link
Contributor

Choose a reason for hiding this comment

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

The fact that this is pub(crate) is good given its specialized nature (and potential possibility of change)

datafusion/physical-expr/src/functions.rs Outdated Show resolved Hide resolved
datafusion/physical-expr/src/functions.rs Outdated Show resolved Hide resolved
@isidentical
Copy link
Contributor Author

I wonder if you have any benchmark results that show this pattern improving performance?

Yep, I was playing with the idea of using the existing null buffers for regex_replace when I noticed that almost ~30% of the time was spent on here (if the input is a sparse-ish array). The example here isidentical#3 shows about ~%20-25 speed-up, and if we go and make it even more sparse the speed-up factor can increase up to %30-%35 (since there isn't much regex processing, all the time was spent on padding arrays with data we won't be using at all).

Also a subsequent optimization (using the existing null buffers) was unnoticeable before this change, but now we can clearly see the benefit of it since the actual time is now spent on result array construction inside regex_replace (instead of array padding on the scalar adapter).

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.

Looks great @isidentical !

(_, true, true, true) => Ok(make_scalar_function_with_hints(
_regexp_replace_static_pattern_replace::<T>,
vec![
Hint::Pad,
Copy link
Contributor

Choose a reason for hiding this comment

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

😍

@alamb
Copy link
Contributor

alamb commented Oct 11, 2022

Thanks again @isidentical

@ursabot
Copy link

ursabot commented Oct 11, 2022

Benchmark runs are scheduled for baseline = 8db6af2 and contender = f132259. f132259 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
physical-expr Physical Expressions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow specialized physical functions to provide hints for the array adapter
3 participants