Impl RleV1Encoder for integer

[suxiaogang223]

close #23
Algorithm adapted from: https://github.com/apache/orc/blob/main/java/core/src/java/org/apache/orc/impl/RunLengthIntegerWriter.java

[Jefffrey]

Thanks for raising this, have left some comments 🙂

[Jefffrey]

Looking better now. Some CI failures to address (can ignore the Cargo Deny License Check failure)

[suxiaogang223]

@Jefffrey I use a fixed-size array on the stack instead of a heap-allocated Vec now. Perhaps we can use the same approach in the implementation of rle_v2 to avoid memory allocation. https://github.com/datafusion-contrib/orc-rust/blob/main/src/encoding/integer/rle_v2/mod.rs#L217

[Jefffrey]

I like where this is headed 👍

[suxiaogang223]

I think it is feasible to use Rc<RefCell> to reuse buffers on the heap. You can check the changes of the last commit.

[Jefffrey]

I think it is feasible to use Rc<RefCell> to reuse buffers on the heap. You can check the changes of the last commit.

At this point it might just be easier to have the Vec directly in the RleV1Encoder itself and not bother having it also in RleV1EncodingState::Literal; I feel that is simpler than having to wrap it in an Rc Refcell

[suxiaogang223]

I think it is feasible to use Rc<RefCell> to reuse buffers on the heap. You can check the changes of the last commit.

At this point it might just be easier to have the Vec directly in the RleV1Encoder itself and not bother having it also in RleV1EncodingState::Literal; I feel that is simpler than having to wrap it in an Rc Refcell

Yes, I think I'm overcomplicating things...

[suxiaogang223]

@Jefffrey Done, can you please review this pr again?🤓