[Java] Experiment with performance difference of avoiding the use of Avro Decoder
- 主要言語
- Java
- スター
- 94
- フォーク
- 152
- 平均マージ
- 3日 16時間
- マージ済み PR(30日)
- 11
説明
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.*
コントリビューションガイド
調査の方向性
まず、Decoder を使用する Java Avro 変換コードを見つけ、既存の Avro zig-zag デコードユーティリティを確認します。ByteBuffer ベースのデコードとそのユーティリティサポートが実装され、Decoder とヒープ上での処理を避けることによって意味のあるパフォーマンスへの影響が得られるかどうかを測定結果で示せれば、作業は完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- data
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100