GH-49720: [C++] Optimize base64_decode validation using lookup table

[Reranko05]

Rationale for this change

The current implementation of base64_decode validates characters using std::string::find for each byte, which introduces unnecessary overhead due to repeated linear searches.

This change replaces those lookups with a precomputed 256-entry lookup table, enabling constant-time validation and value lookup per character.

What changes are included in this PR?

• Introduced a static lookup table (kBase64Lookup) to map base64 characters to their corresponding values
• Replaced std::string::find with constant-time table lookup for character validation

Are these changes tested?

Yes. Existing base64 decoding behavior remains unchanged and continues to pass all current tests. This change is a performance optimization and does not alter functional output.

Are there any user-facing changes?

No.

This change is internal and does not affect public APIs.

• GitHub Issue: [C++] Optimize base64_decode validation using lookup table #49720

[github-actions]

⚠️ GitHub issue #49720 has been automatically assigned in GitHub to PR creator.

[Reranko05]

Hi @kou @dmitry-chirkov-dremio, this implements the lookup-table optimization we discussed in PR #49660 .
Would appreciate your feedback when convenient. Thanks!

[Copilot]

Pull request overview

Optimizes C++ base64_decode character validation by replacing per-character std::string::find lookups with a precomputed 256-entry lookup table.

Changes:

• Added a static 256-entry lookup table (kBase64Lookup) mapping bytes to Base64 sextet values (or invalid marker).
• Updated base64_decode to validate and decode using constant-time table lookup instead of std::string::find.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Reranko05]

Hi @kou, I've addressed the copilot review feedback:

• Added include for fixed-width types
• Fixed narrowing conversion with explicit cast
• Cached lookup result to avoid redundant table access

Please take another look when convenient. Thanks!

[kou]

+1

Have you checked whether this optimization improves performance or not?

[Reranko05]

Hi @kou, I ran a quick benchmark comparing the previous implementation and this change.

Results (200 iterations):

Small (~100B):

• Before: ~0 ms
• After: ~0 ms

Medium (~10KB):

• Before: 58 ms
• After: 12 ms

Large (~1MB):

• Before: 4302 ms
• After: 1126 ms

The improvement is negligible for very small inputs but becomes significant as input size grows. This aligns with expectations, since the change replaces repeated linear std::string::find lookups with constant-time table access per character.

[kou]

Great!

@dmitry-chirkov-dremio do you want to review this before we merge this?

[dmitry-chirkov-dremio]

@Reranko05 do you have before before numbers?

[Reranko05]

Hi @dmitry-chirkov-dremio, just to clarify, by "before before" do you mean comparing against the original implementation prior to #49660, or are you asking for something else?

[Reranko05]

Hi @dmitry-chirkov-dremio, if by “before before” you meant the implementation prior to #49660, here are benchmarks across all three stages:

Before-before (original, pre-#49660):
Small (~100B): ~0 ms
Medium (~10KB): 27 ms
Large (~1MB): 2832 ms

Before (after #49660):
Small (~100B): ~0 ms
Medium (~10KB): 58 ms
Large (~1MB): 4302 ms

After (this PR):
Small (~100B): ~0 ms
Medium (~10KB): 12 ms
Large (~1MB): 1126 ms

The validation changes introduced some overhead (expected due to additional checks), and this optimization not only removes that regression but also improves performance beyond the original implementation by replacing repeated linear lookups with constant-time table access.