Optimize take kernel for BinaryViewArray and StringViewArray

[a10y]

Which issue does this PR close?

Closes #6167 .

Rationale for this change

Improve the performance of take for Utf8View and BinaryView by up to 16x. Here's benchmark results comparing before and after this change, taken with my M2 MBP:

$ critcmp 2905ce6796cad396 2905ce6796cad396-unsafe-v2
group                                            2905ce6796cad396                       2905ce6796cad396-unsafe-v2
-----                                            ----------------                       --------------------------
take str 1024                                    1.15     13.9±2.33µs        ? ?/sec    1.00     12.1±0.28µs        ? ?/sec
take str 512                                     1.00      6.1±0.06µs        ? ?/sec    1.34      8.1±1.49µs        ? ?/sec
take str null indices 1024                       1.02      8.0±0.06µs        ? ?/sec    1.00      7.8±0.08µs        ? ?/sec
take str null indices 512                        1.03      3.7±0.07µs        ? ?/sec    1.00      3.6±0.06µs        ? ?/sec
take str null values 1024                        1.00      7.6±0.06µs        ? ?/sec    1.01      7.7±0.06µs        ? ?/sec
take str null values null indices 1024           1.00      4.6±0.03µs        ? ?/sec    1.06      4.9±0.02µs        ? ?/sec
take stringview 1024                             16.84    14.1±0.17µs        ? ?/sec    1.00    835.0±5.36ns        ? ?/sec
take stringview 512                              12.86     6.3±0.10µs        ? ?/sec    1.00    488.9±4.04ns        ? ?/sec
take stringview null indices 1024                13.79    11.7±0.16µs        ? ?/sec    1.00   848.3±19.98ns        ? ?/sec
take stringview null indices 512                 10.81     5.4±0.07µs        ? ?/sec    1.00    498.2±6.71ns        ? ?/sec
take stringview null values 1024                 5.34      9.1±0.08µs        ? ?/sec    1.00  1708.9±11.28ns        ? ?/sec
take stringview null values null indices 1024    3.01      6.9±0.08µs        ? ?/sec    1.00      2.3±0.06µs        ? ?/sec

What changes are included in this PR?

• Mirror take_byte implementation for take_byte_view by doing a no-validation construction of the array data
• Add stringview to the existing take kernel benchmark suite

Are there any user-facing changes?

No behavior changes just performance.

[a10y]

Looks like benchmarks are the same or better using new_unchecked

group                                            2905ce6796cad396                       new_unchecked
-----                                            ----------------                       -------------
take stringview 1024                             18.71    14.1±0.17µs        ? ?/sec    1.00   751.3±12.43ns        ? ?/sec
take stringview 512                              15.24     6.3±0.10µs        ? ?/sec    1.00   412.7±18.34ns        ? ?/sec
take stringview null indices 1024                15.79    11.7±0.16µs        ? ?/sec    1.00   740.6±30.60ns        ? ?/sec
take stringview null indices 512                 12.23     5.4±0.07µs        ? ?/sec    1.00   440.4±30.70ns        ? ?/sec
take stringview null values 1024                 5.45      9.1±0.08µs        ? ?/sec    1.00  1674.5±71.90ns        ? ?/sec
take stringview null values null indices 1024    2.71      6.9±0.08µs        ? ?/sec    1.00      2.6±0.42µs        ? ?/sec

[XiangpengHao]

Looks good to me! Great to know that take can be even faster!

[alamb]

It is not often we see a 16x performance improvement 🚀 -- thank you @a10y

BTW I got some pretty sweet looking numbers for ClickBench with StringView in DataFusion (details on apache/datafusion#11723). @XiangpengHao mentioed that this implementation will likely make it even better. I'll see if I can run some numbers

[alamb]

Looks good to me @a10y -- I double checked that take_native and take_nulls both check bounds properly

Thanks also to @tustvold and @XiangpengHao for their reviews

[alamb]

Using a max len of 400 means most of the string values will be "long" (not inlined views which happens for values less than 12 bytes in length). I don't think that is critical I am just pointing it out

[a10y]

Yep it's a good point. I do think that the change is going to be more impactful for outlined vs inlined strings, as validation time is linear w.r.t. length of string.

Though, even for the relatively short strings in TPC-H, the validation step was really significant (~22% of execution time)

I have a flamegraph for q10 in spiraldb/vortex#476 (comment).

[alamb]

Thanks again everyone!