GH-49438: [C++][Gandiva] Optimize LPAD/RPAD functions by dmitry-chirkov-dremio · Pull Request #49439 · apache/arrow

dmitry-chirkov-dremio · 2026-03-03T14:35:21Z

Rationale for this change

The lpad_utf8_int32_utf8 and rpad_utf8_int32_utf8 functions have performance inefficiency and a potential memory safety issue:

Performance: Single-byte fills iterate character-by-character when memset would suffice. Multi-byte fills use O(n) iterations instead of O(log n) with a doubling strategy.
Memory safety: When the fill string is longer than the padding space needed, the code could write more bytes than allocated. Fixed preventatively.

What changes are included in this PR?

Memory safety fix: Use std::min(fill_text_len, total_fill_bytes) for the initial copy to prevent overflow
Fast path: Add single-byte fill optimization using memset
General path: Replace character-by-character loop with doubling strategy for multi-byte fills
Tests: Add comprehensive tests for the new code paths

Are these changes tested?

Yes. Added tests covering:

Large UTF-8 fill characters (4-byte emoji, 3-byte Chinese)
Single-byte fill boundaries (1 char and 65536 char padding)
Content verification for fill patterns
Doubling strategy boundaries
Partial fill scenarios (fill text longer than padding needed)

Are there any user-facing changes?

No.

GitHub Issue: [C++][Gandiva] Optimize LPAD/RPAD functions: fix memory safety issue and improve performance #49438

github-actions · 2026-03-03T14:35:48Z

⚠️ GitHub issue #49438 has no components, please add labels for components.

dmitry-chirkov-dremio · 2026-03-03T14:39:04Z

Local Benchmark Results

Platform: Apple M3, macOS
Benchmark: cpp/src/gandiva/tests/micro_benchmarks.cc, 10 repetitions, 1 million rows per test

The original RPAD was pathologically slow compared to LPAD due to different algorithms. For 65K padding: LPAD took ~29ms while RPAD took ~992ms (34x slower for identical operation). The optimization applies the same efficient algorithm to both functions.

LPAD (mean time in μs)

Benchmark	Original	Optimized	Speedup
Minimal (9 padding chars)	147	148	-
Small (99 padding chars)	312	167	1.9x
Medium (100 padding chars)	368	219	1.7x
Large (1000 padding chars)	16,242	16,273	-
XLarge (65436 padding chars)	29,115	27,987	1.04x

RPAD (mean time in μs)

Benchmark	Original	Optimized	Speedup
Minimal (9 padding chars)	247	148	1.7x
Small (99 padding chars)	1,704	165	10x
Medium (100 padding chars)	1,773	216	8x
Large (1000 padding chars)	30,813	16,082	1.9x
XLarge (65436 padding chars)	992,334	27,724	36x

github-actions · 2026-03-03T19:51:09Z

⚠️ GitHub issue #49438 has no components, please add labels for components.

github-actions · 2026-03-03T22:15:01Z

⚠️ GitHub issue #49438 has no components, please add labels for components.

kou · 2026-03-04T00:10:35Z

@lriggs @akravchukdremio @xxlaykxx You may want to review this.

kou

It seems that lpad_utf8_int32_utf8() and rpad_utf8_int32_utf8() have many duplicated code. Can we factor out it as a helper function?

kou

+1

conbench-apache-arrow · 2026-03-13T11:22:14Z

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 5707713.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 1 possible false positive for unstable benchmarks that are known to sometimes produce them.

…9439) ### Rationale for this change The `lpad_utf8_int32_utf8` and `rpad_utf8_int32_utf8` functions have performance inefficiency and a potential memory safety issue: 1. **Performance**: Single-byte fills iterate character-by-character when `memset` would suffice. Multi-byte fills use O(n) iterations instead of O(log n) with a doubling strategy. 2. **Memory safety**: When the fill string is longer than the padding space needed, the code could write more bytes than allocated. Fixed preventatively. ### What changes are included in this PR? 1. **Memory safety fix**: Use `std::min(fill_text_len, total_fill_bytes)` for the initial copy to prevent overflow 2. **Fast path**: Add single-byte fill optimization using `memset` 3. **General path**: Replace character-by-character loop with doubling strategy for multi-byte fills 4. **Tests**: Add comprehensive tests for the new code paths ### Are these changes tested? Yes. Added tests covering: - Large UTF-8 fill characters (4-byte emoji, 3-byte Chinese) - Single-byte fill boundaries (1 char and 65536 char padding) - Content verification for fill patterns - Doubling strategy boundaries - Partial fill scenarios (fill text longer than padding needed) ### Are there any user-facing changes? No. * GitHub Issue: apache#49438 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…eGH-49421 Backport several upstream fixes. (#136) * apacheGH-49420: [C++][Gandiva] Fix castVARCHAR memory allocation and len<=0 handling (apache#49421) ### Rationale for this change The `castVARCHAR` functions in Gandiva have memory allocation inefficiencies and missing edge case handling. See apacheGH-49420 for details. ### What changes are included in this PR? **Functional fixes:** - `bool`: Remove unused 5-byte arena allocation; return string literal directly - `int32`/`int64`: Add handling for `len=0` (return empty string) and `len<0` (set error) **Memory allocation optimizations:** - `int32`/`int64`: Allocate fixed small buffer (11/20 bytes) directly in arena, use optimized digit-pair conversion writing right-to-left, then `memmove` to align. Returns `min(len, actual_size)` bytes. - `date64`: Allocate only `min(len, 10)` bytes upfront (output is always "YYYY-MM-DD") - `float32`/`float64`: Allocate only `min(len, 24)` bytes upfront (max output length) **Code cleanup:** - Extract common code into helper macros to reduce duplication ### Are these changes tested? Yes. Added tests for `len=0` and `len<0` edge cases for int64, date64, float32, float64, and bool types. All existing Gandiva tests pass. Adhoc performance benchmarking was performed both via direct expression evaluation as well as via query execution via Dremio. ### Are there any user-facing changes? No. Users will see reduced memory usage and proper error messages for invalid len parameter values. Note: Error messages for negative `len` remain different between precompiled ("Output buffer length can't be negative") and interpreted ("Buffer length cannot be negative") code paths, preserving existing behavior. * GitHub Issue: apache#49420 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com> * apacheGH-49438: [C++][Gandiva] Optimize LPAD/RPAD functions (apache#49439) ### Rationale for this change The `lpad_utf8_int32_utf8` and `rpad_utf8_int32_utf8` functions have performance inefficiency and a potential memory safety issue: 1. **Performance**: Single-byte fills iterate character-by-character when `memset` would suffice. Multi-byte fills use O(n) iterations instead of O(log n) with a doubling strategy. 2. **Memory safety**: When the fill string is longer than the padding space needed, the code could write more bytes than allocated. Fixed preventatively. ### What changes are included in this PR? 1. **Memory safety fix**: Use `std::min(fill_text_len, total_fill_bytes)` for the initial copy to prevent overflow 2. **Fast path**: Add single-byte fill optimization using `memset` 3. **General path**: Replace character-by-character loop with doubling strategy for multi-byte fills 4. **Tests**: Add comprehensive tests for the new code paths ### Are these changes tested? Yes. Added tests covering: - Large UTF-8 fill characters (4-byte emoji, 3-byte Chinese) - Single-byte fill boundaries (1 char and 65536 char padding) - Content verification for fill patterns - Doubling strategy boundaries - Partial fill scenarios (fill text longer than padding needed) ### Are there any user-facing changes? No. * GitHub Issue: apache#49438 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com> * apacheGH-49441: [C++][Gandiva] Add rand_integer function (apache#49442) ### Rationale for this change Add `rand_integer` function to Gandiva to generate random integers, complementing the existing `rand`/`random` functions that generate random doubles. This provides native integer random number generation and offers a more efficient alternative to `CAST(rand() * range AS INT)`. ### What changes are included in this PR? - Add `RandomIntegerGeneratorHolder` class following the existing `RandomGeneratorHolder` pattern - Implement three function signatures: - `rand_integer()` → int32 in range [INT32_MIN, INT32_MAX] - `rand_integer(int32 range)` → int32 in range [0, range-1] - `rand_integer(int32 min, int32 max)` → int32 in range [min, max] inclusive - Add parameter validation (range > 0, min <= max) at expression compilation time - Add 8 unit tests covering all signatures and edge cases - Use `std::uniform_int_distribution<int32_t>` with Mersenne Twister engine ### Are these changes tested? Yes, added 8 unit tests in `random_generator_holder_test.cc`: - `NoParams` - verifies full int32 range - `WithRange` - verifies [0, range-1] bounds - `WithMinMax` - verifies [min, max] inclusive bounds - `WithNegativeMinMax` - verifies negative range handling - `InvalidRangeZero` - verifies range=0 is rejected - `InvalidRangeNegative` - verifies negative range is rejected - `InvalidMinGreaterThanMax` - verifies min > max is rejected - `NullRangeDefaultsToOne` - verifies null parameter handling ### Are there any user-facing changes? Yes, this adds a new `rand_integer` function to Gandiva with three signatures as described above. * GitHub Issue: apache#49441 * apacheGH-49454: [C++][Gandiva] Fix castVARCHAR_timestamp for pre-epoch timestamps (apache#49455) ### Rationale for this change apacheGH-49454 castVARCHAR_timestamp_int64 produces negative milliseconds for pre-epoch timestamps ### What changes are included in this PR? Fixed `castVARCHAR_timestamp_int64` to correctly handle pre-epoch timestamps (before 1970-01-01). The issue was that using `in % MILLIS_IN_SEC` on negative timestamps produces negative milliseconds, resulting in output like `"0107-10-17 12:20:03.-10"`. ### Are these changes tested? Yes, added 4 new test cases covering pre-epoch timestamps with milliseconds ### Are there any user-facing changes? **This PR contains a "Critical Fix".** This fixes a bug that caused **incorrect data to be produced** when casting pre-epoch timestamps to VARCHAR in Gandiva. Previously, timestamps before 1970-01-01 with non-zero milliseconds would produce invalid output with negative millisecond values (e.g., `"0107-10-17 12:20:03.-10"` instead of `"0107-10-17 12:20:03.900"`). * GitHub Issue: apache#49454 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com> * apacheGH-49470: [C++][Gandiva] Fix crashes in substring_index and truncate with extreme integer values (apache#49471) ### Rationale for this change Two Gandiva functions crash when called with extreme integer parameter values: 1. `substring_index(VARCHAR, VARCHAR, INT)` crashes with SIGBUS when count is `INT_MIN` 2. `truncate(BIGINT, INT)` crashes with SIGSEGV when scale is `INT_MAX` or `INT_MIN` ### What changes are included in this PR? **substring_index fix** (`gdv_string_function_stubs.cc`): - Replace `abs(cnt)` with safe `int64_t` computation to avoid undefined behavior when `cnt == INT_MIN` **truncate fix** (`precompiled/extended_math_ops.cc`): - Return input unchanged for positive scales (no-op for integers) - Return 0 for scales < -38 to prevent out-of-bounds access in `GetScaleMultiplier` ### Are these changes tested? Yes. Added coverage for `INT_MAX`/`INT_MIN` values in `gdv_function_stubs_test.cc` and `extended_math_ops_test.cc`. ### Are there any user-facing changes? No. **This PR contains a "Critical Fix".** These changes fix crashes caused by: - `abs(INT_MIN)` triggering undefined behavior (integer overflow) in `substring_index` - Out-of-bounds array access in `GetScaleMultiplier` when `truncate` receives extreme scale values * GitHub Issue: apache#49470 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Rossi Sun <zanmato1984@gmail.com> --------- Signed-off-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Rossi Sun <zanmato1984@gmail.com> Co-authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com>

…9439) ### Rationale for this change The `lpad_utf8_int32_utf8` and `rpad_utf8_int32_utf8` functions have performance inefficiency and a potential memory safety issue: 1. **Performance**: Single-byte fills iterate character-by-character when `memset` would suffice. Multi-byte fills use O(n) iterations instead of O(log n) with a doubling strategy. 2. **Memory safety**: When the fill string is longer than the padding space needed, the code could write more bytes than allocated. Fixed preventatively. ### What changes are included in this PR? 1. **Memory safety fix**: Use `std::min(fill_text_len, total_fill_bytes)` for the initial copy to prevent overflow 2. **Fast path**: Add single-byte fill optimization using `memset` 3. **General path**: Replace character-by-character loop with doubling strategy for multi-byte fills 4. **Tests**: Add comprehensive tests for the new code paths ### Are these changes tested? Yes. Added tests covering: - Large UTF-8 fill characters (4-byte emoji, 3-byte Chinese) - Single-byte fill boundaries (1 char and 65536 char padding) - Content verification for fill patterns - Doubling strategy boundaries - Partial fill scenarios (fill text longer than padding needed) ### Are there any user-facing changes? No. * GitHub Issue: apache#49438 Authored-by: Dmitry Chirkov <dmitry.chirkov@dremio.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

GH-XXXXX: [C++][Gandiva] Optimize lpad/rpad UTF-8 functions

81c1bde

github-actions Bot added Component: C++ Component: Gandiva awaiting review Awaiting review labels Mar 3, 2026

dmitry-chirkov-dremio changed the title ~~GH-49438: [C++][Gandiva] Optimize lpad/rpad UTF-8 functions~~ GH-49438: [C++][Gandiva] Optimize LPAD/RPAD functions Mar 3, 2026

lriggs approved these changes Mar 6, 2026

View reviewed changes

github-actions Bot added awaiting committer review Awaiting committer review and removed awaiting review Awaiting review labels Mar 6, 2026

kou reviewed Mar 11, 2026

View reviewed changes

Comment thread cpp/src/gandiva/precompiled/string_ops.cc Outdated

Comment thread cpp/src/gandiva/precompiled/string_ops_test.cc Outdated

Comment thread cpp/src/gandiva/precompiled/string_ops_test.cc

github-actions Bot added awaiting changes Awaiting changes awaiting review Awaiting review and removed awaiting committer review Awaiting committer review labels Mar 11, 2026

Address review feedback: extract helper function and simplify tests

85ae4f7

github-actions Bot added awaiting review Awaiting review awaiting committer review Awaiting committer review and removed awaiting review Awaiting review awaiting changes Awaiting changes labels Mar 11, 2026

kou reviewed Mar 11, 2026

View reviewed changes

Comment thread cpp/src/gandiva/precompiled/string_ops.cc Outdated

github-actions Bot added awaiting changes Awaiting changes and removed awaiting committer review Awaiting committer review labels Mar 11, 2026

Add static to internal helper function

8415ac5

github-actions Bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Mar 13, 2026

kou approved these changes Mar 13, 2026

View reviewed changes

kou merged commit 5707713 into apache:main Mar 13, 2026
51 of 52 checks passed

kou removed the awaiting change review Awaiting change review label Mar 13, 2026

kou mentioned this pull request Mar 13, 2026

[C++][Gandiva] Optimize LPAD/RPAD functions: fix memory safety issue and improve performance #49438

Closed

github-actions Bot added the awaiting merge Awaiting merge label Mar 13, 2026

lriggs mentioned this pull request Apr 23, 2026

GH-49471, GH-49455, GH-49442, GH-49439, GH-49421 Backport several upstream fixes. dremio/arrow#136

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

GH-49438: [C++][Gandiva] Optimize LPAD/RPAD functions#49439

GH-49438: [C++][Gandiva] Optimize LPAD/RPAD functions#49439
kou merged 3 commits into
apache:mainfrom
dmitry-chirkov-dremio:gandiva-lpad-optimization

dmitry-chirkov-dremio commented Mar 3, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

dmitry-chirkov-dremio commented Mar 3, 2026

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

kou commented Mar 4, 2026

Uh oh!

kou left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kou left a comment

Uh oh!

Uh oh!

conbench-apache-arrow Bot commented Mar 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

dmitry-chirkov-dremio commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

dmitry-chirkov-dremio commented Mar 3, 2026

Local Benchmark Results

LPAD (mean time in μs)

RPAD (mean time in μs)

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

github-actions Bot commented Mar 3, 2026

Uh oh!

kou commented Mar 4, 2026

Uh oh!

kou left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kou left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

conbench-apache-arrow Bot commented Mar 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dmitry-chirkov-dremio commented Mar 3, 2026 •

edited

Loading