Skip to content

minor: refactor array reverse internals#18445

Merged
Jefffrey merged 1 commit intoapache:mainfrom
Jefffrey:refactor_arr_reverse
Nov 3, 2025
Merged

minor: refactor array reverse internals#18445
Jefffrey merged 1 commit intoapache:mainfrom
Jefffrey:refactor_arr_reverse

Conversation

@Jefffrey
Copy link
Copy Markdown
Contributor

@Jefffrey Jefffrey commented Nov 2, 2025

Which issue does this PR close?

N/A

Rationale for this change

When reviewing #18424 I noticed some refactoring that could be applied to existing array reverse implementation.

What changes are included in this PR?

Are these changes tested?

See my comments for the refactors & justifications.

Existing tests.

Are there any user-facing changes?

No.

Comment on lines -140 to +141
fn general_array_reverse<O: OffsetSizeTrait + TryFrom<i64>>(
fn general_array_reverse<O: OffsetSizeTrait>(
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Unused trait bound

OffsetBuffer::<O>::new(offsets.into()),
arrow::array::make_array(data),
Some(nulls.into()),
array.nulls().cloned(),
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We can directly copy the nulls from the input array instead of recreating it step by step (do the same for fixed size lists below)

MutableArrayData::with_capacities(vec![&original_data], false, capacity);

for (row_index, offset_window) in array.offsets().windows(2).enumerate() {
for (row_index, (&start, &end)) in array.offsets().iter().tuple_windows().enumerate()
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Using tuple_windows from itertools for a nicer interface on grabbing the start & end indices

nulls.push(false);
offsets.push(offsets[row_index] + O::one());
mutable.extend(0, 0, 1);
offsets.push(offsets[row_index]);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We can just have an empty list here since it's null anyway, instead of extending the child array by one element

let end = offset_window[1];

let mut index = end - O::one();
let mut cnt = 0;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

cnt can be determined once up front

@Jefffrey Jefffrey marked this pull request as ready for review November 2, 2025 14:37
@vegarsti
Copy link
Copy Markdown
Contributor

vegarsti commented Nov 2, 2025

Nice!

Copy link
Copy Markdown
Contributor

@adriangb adriangb left a comment

Choose a reason for hiding this comment

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

Nice little cleanup!

@Jefffrey Jefffrey added this pull request to the merge queue Nov 3, 2025
Merged via the queue into apache:main with commit 9238779 Nov 3, 2025
28 checks passed
@Jefffrey Jefffrey deleted the refactor_arr_reverse branch November 3, 2025 03:12
codetyri0n pushed a commit to codetyri0n/datafusion that referenced this pull request Nov 11, 2025
## 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.
-->

N/A

## Rationale for this change

<!--
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.
-->

When reviewing apache#18424 I noticed some refactoring that could be applied
to existing array reverse implementation.

## What changes are included in this PR?

<!--
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?

<!--
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)?
-->

See my comments for the refactors & justifications.

Existing tests.

## Are there any user-facing changes?

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

No.

<!--
If there are any breaking changes to public APIs, please add the `api
change` label.
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants