Improve performance of InternalParquetRecordReader (1%)
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.6k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 33
Description
### Describe the enhancement requested
Profiling the load of a Parquet file with Java Mission Control, I've noticed that `InternalParquetRecordReader` [LongStream](https://github.com/apache/parquet-java/blob/1f1e07bbf750fba228851c2d63470c3da5726831/parquet-hadoop/src/main/java/org/apache/parquet/hadoop/InternalParquetRecordReader.java#L323) consumes relevant amount of time.
This `LongStream` can be replaced with a simpler Long Iterator that iterates from 0 to `pages.getRowCount()`.
To measure the overhead I've created a test project that overwrites `InternalParquetRecordReader` implementation with a Long Iterator: https://github.com/jerolba/parquet-rowindexiterator
The execution time is sensitive to the context of the JVM, but running the benchmark multiple times shows that LongStream is slower than LongIterator, between 1% and 4% depending on the run.
### Component(s)
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in parquet-hadoop/src/main/java/org/apache/parquet/hadoop/InternalParquetRecordReader.java at the LongStream around line 323, then review the linked parquet-rowindexiterator benchmark project. Compare the reader's current iteration with the benchmark's Long Iterator approach; done means the reader avoids the reported LongStream overhead while preserving row-index iteration behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- data-engineering, performance
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100