Rich-T-kid opened a new issue, #10868: URL: https://github.com/apache/arrow-rs/issues/10868
### Is your feature request related to a problem or challenge? Several performance optimizations in arrow-rs (e.g. #10812, take on List<T>) would naturally reach for Vec<u8> or Vec<T>, Rust's stdlib Vec is heavily optimized by the compiler and benefits from inlining, LLVM vectorization hints, and well-understood growth patterns. However, any buffer that will be reinterpreted as a typed `ScalarBuffer<T>` must satisfy T's alignment requirement. `Vec<u8>` only guarantees 1-byte alignment, causing panics like Memory pointer is not aligned with the specified scalar type ### Describe the solution you'd like Introduce a thin newtype in arrow-buffer along the lines of: ``` #[repr(align(64))] struct Align64([u8; 64]); pub struct AlignedVec(Vec<Align64>); ``` that exposes a Vec-compatible interface (push, extend_from_slice, len, as_slice, etc.) while guaranteeing 64-byte alignment. This would let optimization hot paths use idiomatic Vec patterns and get full compiler/LLVM optimization benefits without sacrificing Arrow's alignment invariants. *this would surely need more work than this, but just a loose idea* ### Describe alternatives you've considered sticking with MutableBuffer ### Additional context this has been a common issue I've encountered when trying to optimize portions of the code base. #10812 recently occurred where switching from `Vec<u8>` to MutableBuffer caused a [30% regression](https://github.com/apache/arrow-rs/pull/10812#issuecomment-5429213753) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
