Skip to content

perf: Optimize trunc scalar performance#19788

Merged
Jefffrey merged 5 commits intoapache:mainfrom
kumarUjjawal:perf/trunc_scalar
Jan 17, 2026
Merged

perf: Optimize trunc scalar performance#19788
Jefffrey merged 5 commits intoapache:mainfrom
kumarUjjawal:perf/trunc_scalar

Conversation

@kumarUjjawal
Copy link
Copy Markdown
Contributor

@kumarUjjawal kumarUjjawal commented Jan 13, 2026

Which issue does this PR close?

Rationale for this change

The current trunc implementation always converts scalar inputs to arrays via make_scalar_function, which introduces unnecessary overhead when processing single values.

What changes are included in this PR?

  • Add scalar fast path for trunc function to process Float32/Float64 scalar inputs directly
  • Handle optional precision argument for scalar inputs
  • Add scalar benchmarks to measure performance

Are these changes tested?

Yes all sqllogictest pass

Benchmark Results

Type Before After Speedup
f64 scalar 256 ns 55 ns 4.6x
f32 scalar 247 ns 56 ns 4.4x

Are there any user-facing changes?

No

@github-actions github-actions Bot added the functions Changes to functions implementation label Jan 13, 2026
martin-g
martin-g reviewed Jan 13, 2026
View reviewed changes
Comment thread datafusion/functions/src/math/trunc.rs Outdated
match &args.args[1] {
ColumnarValue::Scalar(Int64(Some(p))) => *p,
ColumnarValue::Scalar(Int64(None)) => {
return Ok(ColumnarValue::Scalar(ScalarValue::Float64(None)));
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

I think this should check the scalar type to decide whether to return Float64 or Float32

Comment thread datafusion/functions/src/math/trunc.rs

fn compute_truncate32(x: f32, y: i64) -> f32 {
let factor = 10.0_f32.powi(y as i32);
(x * factor).round() / factor
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

Not introduced in this PR but why f32::round() is used here instead of f32::trunc() ?
Same for f64 below.

fn main() {
    let factor = 10_f64;
    let r = (3.76_f64 * factor).round() / factor;
    let t = (3.76_f64 * factor).trunc() / factor; 
    println!("round: {r}\ntrunc: {t}");
}

prints:

round: 3.8
trunc: 3.7

Copy link
Copy Markdown
Contributor Author

@kumarUjjawal kumarUjjawal Jan 13, 2026

Choose a reason for hiding this comment

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

Yeah it does seem like a bug. I will file an issue

Copy link
Copy Markdown
Contributor Author

@kumarUjjawal kumarUjjawal Jan 13, 2026

Choose a reason for hiding this comment

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

filed #19793

Comment thread datafusion/functions/src/math/trunc.rs Outdated
};

match scalar {
ScalarValue::Float64(v) => {
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

Fast path for ScalarValue::Null too ?!

Comment thread datafusion/functions/src/math/trunc.rs Outdated
ScalarValue::Float64(v) => {
let result = v.map(|x| {
if precision == 0 {
if x == 0.0 { 0.0 } else { x.trunc() }
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
if x == 0.0 { 0.0 } else { x.trunc() }
x.trunc()

Comment thread datafusion/functions/src/math/trunc.rs Outdated
ScalarValue::Float32(v) => {
let result = v.map(|x| {
if precision == 0 {
if x == 0.0 { 0.0 } else { x.trunc() }
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
if x == 0.0 { 0.0 } else { x.trunc() }
x.trunc()

Comment thread datafusion/functions/benches/trunc.rs Outdated
)];
let scalar_arg_fields = vec![Field::new("a", DataType::Float64, false).into()];
let scalar_return_field = Field::new("f", DataType::Float64, false).into();
let config_options = Arc::new(ConfigOptions::default());
Copy link
Copy Markdown
Member

@martin-g martin-g Jan 13, 2026

Choose a reason for hiding this comment

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

nit: This variable shadows the same one from line 40

@kumarUjjawal
Copy link
Copy Markdown
Contributor Author

kumarUjjawal commented Jan 13, 2026

Thanks for the feedback @martin-g, incorporated the changes.

Jefffrey
Jefffrey reviewed Jan 14, 2026
View reviewed changes
Comment thread datafusion/functions/src/math/trunc.rs Outdated
Jefffrey
Jefffrey reviewed Jan 14, 2026
View reviewed changes
Comment thread datafusion/functions/src/math/trunc.rs Outdated
return make_scalar_function(trunc, vec![])(&args.args);
}
None => Some(0), // default precision
_ => Some(0),
Copy link
Copy Markdown
Contributor

@Jefffrey Jefffrey Jan 14, 2026

Choose a reason for hiding this comment

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

This catch all arm should return an internal error, unless theres a case I'm missing?

Copy link
Copy Markdown
Contributor Author

@kumarUjjawal kumarUjjawal Jan 15, 2026

Choose a reason for hiding this comment

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

Yes it should. Made changes

Comment thread datafusion/functions/src/math/trunc.rs Outdated
kumarUjjawal and others added 2 commits January 14, 2026 22:29
@kumarUjjawal @Jefffrey
suggestion from Jeffrey
0180eb6 
Co-authored-by: Jeffrey Vo <jeffrey.vo.australia@gmail.com>
@kumarUjjawal
catch arm returns exec_err! with message
e6e2825
@Jefffrey Jefffrey added this pull request to the merge queue Jan 17, 2026
Merged via the queue into apache:main with commit 3ea21aa Jan 17, 2026
28 checks passed
@Jefffrey
Copy link
Copy Markdown
Contributor

Jefffrey commented Jan 17, 2026

Thanks @kumarUjjawal & @martin-g

de-bgunter pushed a commit to de-bgunter/datafusion that referenced this pull request Mar 24, 2026
@kumarUjjawal @Jefffrey @de-bgunter
perf: Optimize trunc scalar performance (apache#19788)
a0690b4 
## Which issue does this PR close?

<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases.
You can link an issue to this PR using the GitHub syntax. For example
`Closes apache#123` indicates that this PR will close issue apache#123.
-->

- Part of apache/datafusion-comet#2986.

## Rationale for this change

The current `trunc` implementation always converts scalar inputs to
arrays via `make_scalar_function`, which introduces unnecessary overhead
when processing single values.

<!--
Why are you proposing this change? If this is already explained clearly
in the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand
your changes and offer better suggestions for fixes.
-->

## What changes are included in this PR?

- Add scalar fast path for `trunc` function to process Float32/Float64
scalar inputs directly
- Handle optional precision argument for scalar inputs
- Add scalar benchmarks to measure performance

<!--
There is no need to duplicate the description in the issue here but it
is sometimes worth providing a summary of the individual changes in this
PR.
-->

## Are these changes tested?

Yes all sqllogictest pass

## Benchmark Results

| Type | Before | After | Speedup |
|------|--------|-------|---------|
| f64 scalar | 256 ns | 55 ns | **4.6x** |
| f32 scalar | 247 ns | 56 ns | **4.4x** |

<!--
We typically require tests for all PRs in order to:
1. Prevent the code from being accidentally broken by subsequent changes
2. Serve as another way to document the expected behavior of the code

If tests are not included in your PR, please explain why (for example,
are they covered by existing tests)?
-->

## Are there any user-facing changes?

No

<!--
If there are user-facing changes then we may require documentation to be
updated before approving the PR.
-->

<!--
If there are any breaking changes to public APIs, please add the `api
change` label.
-->

---------

Co-authored-by: Jeffrey Vo <jeffrey.vo.australia@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@martin-g martin-g martin-g left review comments

@Jefffrey Jefffrey Jefffrey approved these changes

Assignees

No one assigned

Labels

functions Changes to functions implementation

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kumarUjjawal @Jefffrey @martin-g