Mryange opened a new pull request, #63386:
URL: https://github.com/apache/doris/pull/63386
### What problem does this PR solve?
Issue Number: N/A
Problem Summary:
Array functions like `array_distance` and `array_join` previously required
hand-written boilerplate to unwrap `Const`, `Nullable`, and plain
`ColumnArray`
variants before accessing element data. This led to duplicated code, manual
offset arithmetic, and a proliferation of helper structs (`ConstArrayInfo`,
`ColumnArrayExecutionData`, etc.).
Root cause: there was no shared abstraction for "read a row of an array
column
regardless of its outer wrapper". Each function solved this independently,
accumulating inconsistent patterns.
This PR introduces `ColumnArrayView<PType>` (and its row-accessor
`ArrayDataView<PType>`) in `be/src/core/column/column_array_view.h`.
The view is created once via `ColumnArrayView::create(col)` and handles
Const/Nullable unwrapping automatically. Per-row access via `operator[](row)`
returns an `ArrayDataView` with `get_data()`, `size()`, and `is_null_at()`
— a uniform interface regardless of the underlying column shape.
For ultra-light nullable primitive loops, `ColumnArrayView` also exposes
flat-access helpers (`get_data()`, `get_null_map_data()`, `row_begin()`,
`row_end()`) so callers can keep wrapper unwrapping centralized while still
iterating directly over the flattened buffers when benchmark data shows that
per-element row-view access would regress.
**Benchmark results** (4096 rows, RELEASE build, `--benchmark_repetitions=5`
on a
shared host with CPU scaling enabled; raw outputs saved in
`benchmark_array_view_raw_results_20260519.txt` and
`benchmark_array_view_distance_split_raw_results_20260519.txt`):
**Row-view access (`operator[]` / `ArrayDataView`)**
| Scenario | Handwritten CPU (ns) | ColumnArrayView CPU (ns) | Delta |
|---|---|---|---|
| Distance Plain/Plain | 322530 | 311276 | **-3.5%** |
| Distance Const/Plain | 301473 | 289794 | **-3.9%** |
| Distance Nullable/Plain | 305970 | 313687 | +2.5% |
| Int64 Plain sum | 15971 | 16036 | +0.4% |
| Int64 WithNulls sum | 26700 | 29497 | +10.5% |
| String Plain len-sum | 16857 | 17120 | +1.6% |
| Int64 Const sum | 16051 | 16148 | +0.6% |
| Int64 Nullable sum | 16198 | 16174 | -0.1% |
**Flat-access follow-up (`get_data()` / `get_null_map_data()` /
`row_begin()` / `row_end()`)**
| Scenario | Handwritten CPU (ns) | ColumnArrayView Flat CPU (ns) | Delta |
|---|---|---|---|
| Int64 WithNulls sum | 26700 | 26765 | +0.2% |
| Distance Plain/Plain | 322530 | 301274 | **-6.6%** |
| Distance Const/Plain | 301473 | 314259 | +4.2% |
| Distance Nullable/Plain | 305970 | 314077 | +2.7% |
Most production-shaped cases stay within a few percent on this shared host.
The only stable double-digit regression is the synthetic `Int64 WithNulls`
microbenchmark, where each element performs only `if (!null) sum += val`.
The flat-access helper path removes that regression (+0.2% vs handwritten)
while keeping `Const` / `Nullable` unwrapping centralized in
`ColumnArrayView`.
Because these numbers were collected on a shared machine with CPU scaling
enabled, the distance cases show visible run-to-run noise;
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason <!-- Add your reason? -->
- Behavior changed:
- [ ] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [ ] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR should
merge into -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
