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

[dmitry-chirkov-dremio]

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: [C++][Gandiva] Optimize LPAD/RPAD functions: fix memory safety issue and improve performance #49438

[github-actions]

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

[dmitry-chirkov-dremio]

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]

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

[github-actions]

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

[kou]

@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]

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.