perf: optimize compute.Take for fewer memory allocations

[hamilton-earthscope]

Rationale for this change

When writing data to partitioned Iceberg tables using iceberg-go's new partitioned write capability, I found that Arrow's compute.Take operation was causing the writes to be significantly slower than unpartitioned writes.

Causes:

• the VarBinaryImpl function here in arrow-go was pre-allocating the data buffer with only meanValueLen (size for just one string/buffer), not the total size needed for all strings. For, my use case (writing 100k rows at a time) this was causing 15x buffer reallocations as the buffer incrementally scales up. For my iceberg table with 20+ string/binary cols of various size this is significant overhead.
• when VarBinaryImpl allocates additional space for new items, it would only add the exact amount needed for the new value. This caused O(n) reallocations.

What changes are included in this PR?

1. Pre-allocate upfront with a better estimate of the necessary buffer size to eliminate repeated reallocations.

   I somewhat arbitrarily chose a cap of 16MB as a guess at what would be effective at reducing the number of allocations but also trying to be cognizant of the library being used in many bespoke scenarios and not wanting to make massive memory spikes. For my use case, I never hit this 16MB threshold and it could be smaller.

   I am curious for your input on whether there should be a cap at all or what a reasonable cap would be.

2. Use exponential growth for additional allocations for O(log n) total reallocations.

Are these changes tested?

No unit tests.

However, with a dedicated reproducing script that mimics my use case with different write sizes (on a macbook pro m3 max + 64GB ram) average of 3 table.Append() calls:

Configuration	100k rows	500k rows	1M rows	2.5M rows	10M rows
Before	4.1s	53.3s	didn't try	didn't try	didn't try
Change 1	336ms	2.41s	8.75s	cancelled after 5mins	didn't try
Change 2	227ms	897ms	1.72s	4.10s	17.1s

Are there any user-facing changes?

No; just more performant

[zeroshade]

Can we add a benchmark test to compute/vector_selection_test.go for future reference?

[hamilton-earthscope]

on main:

go test -bench=BenchmarkTakeString -benchmem -benchtime=3x -run=^$ -timeout 30m
goos: darwin
goarch: arm64
pkg: github.com/apache/arrow-go/v18/arrow/compute
cpu: Apple M3 Max
BenchmarkTakeString/SmallBatch_ShortStrings-16                 3            139750 ns/op           7163478 rows/sec       835890 B/op         198 allocs/op
BenchmarkTakeString/MediumBatch_ShortStrings-16                3          13052111 ns/op            766200 rows/sec     98296896 B/op        1762 allocs/op
BenchmarkTakeString/LargeBatch_ShortStrings-16                 3         193090167 ns/op            258947 rows/sec     2746571538 B/op      9389 allocs/op
BenchmarkTakeString/XLargeBatch_ShortStrings-16                3         564450403 ns/op            177164 rows/sec     11119508282 B/op    18947 allocs/op
BenchmarkTakeString/SmallBatch_MediumStrings-16                3           3269042 ns/op            305968 rows/sec     21126634 B/op         826 allocs/op
BenchmarkTakeString/MediumBatch_MediumStrings-16               3         198658722 ns/op             50338 rows/sec     2055054277 B/op      8127 allocs/op
BenchmarkTakeString/LargeBatch_MediumStrings-16                3        2286152306 ns/op             21871 rows/sec     52530632896 B/op    41554 allocs/op
BenchmarkTakeString/XLargeBatch_MediumStrings-16               3        8208929458 ns/op             12182 rows/sec     210687783749 B/op           83644 allocs/op
BenchmarkTakeString/LargeBatch_ShortStrings_Large-16           3         183346069 ns/op            272709 rows/sec     2746760874 B/op      9312 allocs/op
BenchmarkTakeString/XLargeBatch_MediumStrings_Large-16         3        8180564000 ns/op             12224 rows/sec     210688177797 B/op           83568 allocs/op
BenchmarkTakeStringPartitionPattern-16                         3         378207430 ns/op            132203 rows/sec     6315631330 B/op     14193 allocs/op
PASS
ok      github.com/apache/arrow-go/v18/arrow/compute    81.473s

this PR:

go test -bench=BenchmarkTakeString -benchmem -benchtime=3x -run=^$ -timeout 30m
goos: darwin
goarch: arm64
pkg: github.com/apache/arrow-go/v18/arrow/compute
cpu: Apple M3 Max
BenchmarkTakeString/SmallBatch_ShortStrings-16                 3             42167 ns/op          23920202 rows/sec        17906 B/op          44 allocs/op
BenchmarkTakeString/MediumBatch_ShortStrings-16                3            156903 ns/op          63869468 rows/sec       160456 B/op          44 allocs/op
BenchmarkTakeString/LargeBatch_ShortStrings-16                 3            760750 ns/op          65783472 rows/sec       805077 B/op          43 allocs/op
BenchmarkTakeString/XLargeBatch_ShortStrings-16                3           1148056 ns/op          87144906 rows/sec      1614917 B/op          43 allocs/op
BenchmarkTakeString/SmallBatch_MediumStrings-16                3             29931 ns/op          33707865 rows/sec        64749 B/op          42 allocs/op
BenchmarkTakeString/MediumBatch_MediumStrings-16               3            229431 ns/op          43689299 rows/sec       562298 B/op          42 allocs/op
BenchmarkTakeString/LargeBatch_MediumStrings-16                3            705195 ns/op          70951339 rows/sec      2812080 B/op          42 allocs/op
BenchmarkTakeString/XLargeBatch_MediumStrings-16               3           1352417 ns/op          73981205 rows/sec      5612592 B/op          42 allocs/op
BenchmarkTakeString/LargeBatch_ShortStrings_Large-16           3            571167 ns/op          87591241 rows/sec      1001650 B/op          42 allocs/op
BenchmarkTakeString/XLargeBatch_MediumStrings_Large-16         3           1353181 ns/op          73933345 rows/sec      6014005 B/op          42 allocs/op
BenchmarkTakeStringPartitionPattern-16                         3            650014 ns/op          76983953 rows/sec      1312954 B/op          42 allocs/op
PASS
ok      github.com/apache/arrow-go/v18/arrow/compute    0.585s