Optimize `ArrowBytesViewMap`

[Dandandan]

Is your feature request related to a problem or challenge?

There seem some opportunities for optimizing ArrowBytesViewMap using some more cleverness.

For e.g. ClickBench query 5, >50% CPU is spent during intern:

A lot of it relates to getting / comparing the bytes from the buffers, etc (append_value, get_value, memcmp, makeview, etc).

Describe the solution you'd like

We should be able to avoid (re)creating views every time and comparing against slices, by storing/comparing the views directly, and avoiding the overhead of the GenericByteViewBuilder methods.

To do so, I think we need:

• Not use values.iter() but use the view buffer and get buffer index
• Compare against the original view (and buffer in the index if needed)
• Update the new view with the new index (don't create it again).

Describe alternatives you've considered

No response

Additional context

No response

[Tushar7012]

Hi @Dandandan

I'd like to work on this issue! I've analyzed the codebase and have a proposed approach:

Optimization Strategy:

1. Store u128 view in Entry struct - enables fast comparison without dereferencing
2. Use values.views() instead of values.iter() - direct access to raw views
3. Fast path for inline strings (≤12 bytes) - compare u128 views directly (single instruction)
4. Prefix comparison for larger strings - check 4-byte prefix before full byte comparison

Expected Impact:

• Inline strings: Near 100% faster comparison (u128 vs byte-by-byte)
• Large strings: Faster rejection via prefix check before dereferencing
• Trade-off: +16 bytes memory per unique string in hash table

Files to modify:

• datafusion/physical-expr-common/src/binary_view_map.rs

I have a working implementation ready. Will create a PR with benchmark results shortly.

[Dandandan]

That sounds amazing, thanks for taking this!

Wrt: Trade-off: +16 bytes memory per unique string in hash table: I think you are able to keep just the (usize) index into the new views as storage if memory is a concern, (or store it not at all externally).