Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improve `RunLengthBitPackingHybridDecoder.readNext` to avoid per-call buffer allocation and `DataInputStream` wrapping

Aperta Adatta ai principianti
  • Qualcosa non va?
#3,466 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
data

Direzione di ricerca

Inizia in parquet-column/src/main/java/org/apache/parquet/column/values/rle/RunLengthBitPackingHybridDecoder.java, concentrandoti sul percorso PACKED-mode in readNext() intorno alle righe 94–98 e sul TODO esistente. Traccia il modo in cui vengono utilizzati i buffer e le letture dell’input, quindi esegui i test pertinenti del decoder. Il lavoro è completato quando chiamate ripetute in PACKED-mode riutilizzano buffer di dimensioni sufficienti senza creare wrapper DataInputStream a ogni chiamata, preservando al contempo il comportamento della decodifica.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Type: enhancement
Describe the enhancement requested

RunLengthBitPackingHybridDecoder.readNext() allocates a new int[] and byte[] on every PACKED-mode call. In workloads that decode many bit-packed runs (definition levels, repetition levels, RLE-encoded integers), these allocations dominate the read-side allocation profile. The upstream code even acknowledges this with a // TODO: reuse a buffer comment.

Problem 1: per-call buffer allocation

Lines 94–95 allocate fresh arrays on every PACKED-mode readNext():

currentBuffer = new int[currentCount]; // TODO: reuse a buffer
byte[] bytes = new byte[numGroups * bitWidth];

currentCount is always numGroups * 8, and numGroups is typically small (1–16 groups = 8–128 values per run). These allocations are individually modest but occur thousands of times per column chunk — once per bit-packed run. In a 180M-row merge with multiple integer/boolean columns, the cumulative allocation is substantial.

Since currentCount varies between runs (different numGroups values), the fix retains the field-level int[] and a new field-level byte[], growing them only when the next run requires a larger buffer.

Problem 2: per-call DataInputStream wrapping

Line 98 creates a new DataInputStream(in) on every PACKED-mode call:

new DataInputStream(in).readFully(bytes, 0, bytesToRead);

This allocates a DataInputStream wrapper object per call just to access readFully(). A private readFully() method on the decoder itself eliminates this allocation and the virtual dispatch through the wrapper.

Component(s)

Core

Lingua principale
Java
Stelle
3.1k
Fork
1.6k
Merge medio
4g 9h
PR unite (30g)
32

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/parquet-java

Tutte le issue di apache/parquet-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.