Reduce allocations in ParquetMetaData for improved performance

[alamb]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

• While working on Measure best case performance for the new thrift-remodel / custom thrift parser #8441

I noticed almost 15% of the time of the benchmark was due to free'ing ParquetMetaData -- this is almost certainly overhead from the individual allocations (perhaps Strings for statistics) in the structure:

Describe the solution you'd like
Reduce the time spent on deallocating this structure to improve benchmarks

Describe alternatives you've considered

Additional context

[etseidl]

I think a bump allocator would help here, but that likely won't be stable any time soon.

[etseidl]

I'd point out here that it seems the largest allocation culprits are the encoding vectors (for Encoding and PageEncodingStats).

[alamb]

I think a bump allocator would help here, but that likely won't be stable any time soon.

I mean we can fake that internally (build a Vec<u8> and store offsets, for example) but it isn't a great idea unless we exhaust all other options

[feniljain]

Hey @etseidl 👋🏻

Sorry for a bit off-topic doubt: What did you use to get memory flamegraph you have shown here 😅

[etseidl]

Samply 😀

https://github.com/mstange/samply

[Dandandan]

I think what might help generally is transform the structure to have a single Vec<Item> in a top level struct (while building) and store a reference / slice in the structs, so it can allocate / deallocate in large chunks (and aditionally helps with cache efficiency / reduces total memory usage).

[jhorstmann]

I think encodings and page encoding stats could benefit from a more specialized container instead of Vec. Encodings could be a small fixed-size bitset and for the stats we could define a more opinionated structure that just contains the number of dictionary-encoded and non-dictionary-encoded pages.

[etseidl]

In addition to exploring #8517 solutions, I've implemented @jhorstmann's suggestion for the encodings vector and that made a significant difference. That along with skipping (for now) statistics and page encoding statistics results in a further 25-35% reduction in decoding time.

[etseidl]

Here's a benchmark using all of the suggested optimizations so far (including skipping column chunk statistics and page encoding statistics). This is compared to the head of the feature branch from #8530.

group                             all_opt                                gh5854
-----                             -------                                ------
decode parquet metadata           1.00     13.5±0.27µs        ? ?/sec    1.45     19.5±0.37µs        ? ?/sec
decode parquet metadata (wide)    1.00     49.8±1.04ms        ? ?/sec    1.82     90.7±3.11ms        ? ?/sec
open(default)                     1.00     14.2±0.24µs        ? ?/sec    1.49     21.2±0.64µs        ? ?/sec
open(page index)                  1.00    251.7±4.43µs        ? ?/sec    1.02    257.5±5.27µs        ? ?/sec

[alamb]

😮