improve zip performance

[rluvaton]

Which issue does this PR close?

No issue

Rationale for this change

I saw that we do for every range of true check if the truthy values and falsy are scalar, which can be checked once

What changes are included in this PR?

1. Specialize cases for scalars in zip function
2. Add extend_scalar function to MutableArrayData to be optimized for single value that is being copy over and over again

Are there any user-facing changes?

No (I think)

---

there are no benchmarks to zip unfortunately

[tustvold]

Suggested change

	pub fn extend_scalar(&mut self, index: usize, scalar_index: usize, count: usize) {
	pub fn extend_n(&mut self, index: usize, scalar_index: usize, count: usize) {

Scalars don't really exist as a notion at this level

[tustvold]

Perhaps you might be able to contribute a benchmark showing the performance difference, there is a lot going on in this kernel and it isn't immediately clear to me that the dyn dispatch in MutableArrayData won't dominate.

[rluvaton]

Perhaps you might be able to contribute a benchmark showing the performance difference, there is a lot going on in this kernel and it isn't immediately clear to me that the dyn dispatch in MutableArrayData won't dominate.

I actually started to create a (WIP) PR to avoid this dyn dispatch:

• Improve performance by specializing mutable array data for each data type  #6815

[tustvold]

I actually started to create a (WIP) PR to avoid this dyn dispatch:

The dyn dispatch is unavoidable in the general case, as arrow supports arbitrarily nested data structures.

Generally the approach is to have specialized kernel implementations for non-nested types where this yields better performance, and then fallback to type-erased versions where this isn't possible

[rluvaton]

So I did local benchmarks and it did not improve the perf from what I saw, so closing