ARROW-10722: [Rust][DataFusion] Reduce overhead of some data types in aggregations / joins, improve benchmarks

[Dandandan]

This PR reduces the size of GroupByScalar from 32 bytes to 16 bytes by using Box<String>. This will reduce the size of a Vec<GroupByScalar> and thus the key of hashmaps used for aggregates / joins.
Also, it changes the type of the key to Box<[GroupByScalar]> to reduce memory usage further by 8 bytes per key needed to hold the capacity of the vec.
Finally we can remove a Box around the Vec holding the indices.

Difference in speed seems to be minimal, at least in current state.

I think in the future, it could be nice to see if the data could be packed efficiently in one Box<[T]> (where T is a primitive value) when having no dynamically sized types by using the schema instead of creating "dynamic" values. That should also make the hashing faster. Currently, when grouping on multiple i32 values, we need 32 bytes per value (next to 24 bytes for the Vec holding the values) instead of just 4! Also using const generics https://rust-lang.github.io/rfcs/2000-const-generics.html#:~:text=Rust%20currently%20has%20one%20type,implement%20traits%20for%20all%20arrays could provide a further improvement (by not having to store the length of the slice).

This PR also tries to improve reproducability in the benchmarks a bit by using the seed in the random number generator (still a quite noisy on my machine though).

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10722

[Dandandan]

Some further tweaks, uses Box<[GroupByScalar]> as key now to avoid a further 8 bytes in the key.

[jorgecarleitao]

Genuinely curious: does the key size has such a large impact? Or is there any memory constraints that you are looking for?

[Dandandan]

@jorgecarleitao Not really on performance as current benchmarks / queries show, just looking at ways to improve the aggregate / join performance.

The main thing I wanted to investigate is whether the aggregates / join can be made faster itself. I think one part would be to create a key that can be hashed faster. Now the hashing algorithm hashes each individual GroupByValue instead of working on a byte array. The latter is in principle faster. Also, some specialized code could also be made for hashing based on 1 column only.

The current changes have a larger impact on memory usage though if you are hashing / aggregating something with high cardinality as each key will generate extra bytes based on 16 bytes for each GroupByValue, 8 bytes for using Vec and 8 bytes for boxing the inner Vec of the aggregation per row. So in a extreme case 32 bytes per row extra where every key is unique.

[jorgecarleitao]

LGTM. Thanks a lot, @Dandandan !

[jorgecarleitao]

Can you rebase this, so that I can merge it?

[Dandandan]

@jorgecarleitao thanks, updated against master!

[Dandandan]

Did also some test against master, it looks like this PR also has some small runtime savings on join queries, I think mostly because of .clone() being cheaper now. Will do some profiling later.
Would be nice to have some criterion benchmarks later to cover joins too & I think it would make sense to have some benchmarks / profiling covering maximum memory usage too.

[Dandandan]

I also have a follow-up on this PR which converts the key for the values to Vec<u8> for the hash joins which is again faster as well. Also reading up a bit on hash join algorithms... It looks like resolving the hash collisions is mostly done afterwards instead of in a hash map directly. I guess that could also be a bit easier, as we don't have to copy the data in the hashmap itself but can keep them in the columns/rows themselves. Would be interesting if we can hash a list of columns much more efficiently this way (e.g. hashing whole columns instead).