[Java] Experiment with performance difference of avoiding the use of Avro Decoder
- Vorherrschende Sprache
- Java
- Sterne
- 94
- Forks
- 152
- Ø Merge
- 3 T. 16 Std.
- Gemergte PRs (30 T.)
- 11
Beschreibung
It has been posited that the Decoder object (and on-heap work in general) is potentially slow for decoding.
The scope of this Jira is to add a new method that instead of consuming from Decoder, consumes directly from a ByteBuffer. In order to this we there needs to be utility classes for zig-zag decoding (one might existing in avro) from a ByteBuffer.
This is esentially rewriting logic in the decoder to work directly against a bytebuffer and then measure if there is a meaningful performance impact.
**Reporter**: [Micah Kornfield](https://issues.apache.org/jira/browse/ARROW-6593) / @emkornfield
#### Related issues:
- [[Java] Add support for skipping decoding of columns/field in Avro converter](https://github.com/apache/arrow/issues/22949) (is a clone of)
**Note**: *This issue was originally created as [ARROW-6593](https://issues.apache.org/jira/browse/ARROW-6593). Please see the [migration documentation](https://github.com/apache/arrow/issues/14542) for further details.*
Beitragsleitfaden
Rechercherichtung
Beginne damit, den Java-Avro-Konvertierungscode zu finden, der Decoder verwendet, und überprüfe alle vorhandenen Avro-Hilfsfunktionen zur Zig-Zag-Decodierung. Die Arbeit ist abgeschlossen, wenn die auf ByteBuffer basierende Decodierung und ihre Hilfsfunktionen implementiert sind und Messungen zeigen, ob das Vermeiden von Decoder und Heap-Arbeit einen signifikanten Leistungseffekt hat.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- java
- Bereich
- data
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 25/100