klion26 opened a new issue, #7978:
URL: https://github.com/apache/arrow-rs/issues/7978

   **Is your feature request related to a problem or challenge? Please describe 
what you are trying to do.**
   <!--
   A clear and concise description of what the problem is. Ex. I'm always 
frustrated when [...] 
   (This section helps Arrow developers understand the context and *why* for 
this feature, in addition to  the *what*)
   -->
   
   This comes from the comments for pr #7977 
   
   > One thing I don't love about this approach is the independent calculation 
of the splice size vs. the bytes that actually get inserted. If they ever 
disagreed... badness as the insertions underflow or overflow the splice. 
   
   > Ideally, we could produce an iterator that emits the desired bytes, and 
the splice itself can guarantee correct behavior. But for that to work the 
iterator would need to provide an accurate lower bound, so which rules out 
`std::iter::from_fn`. Even if we did craft a custom iterator, computing its 
lower bound would basically be this same calculation all over again. We could 
also chain together a bunch of iterators, which preserves the lower bound, but 
somehow I doubt that would be efficient.
   
   _Originally posted by @scovich in 
https://github.com/apache/arrow-rs/pull/7935#discussion_r2216928879_
   
   > Or try the other approach that populates the tmp vec with non-zero bytes 
before splicing it into the main buffer? That's a lot simpler than this 
iterator-based suggestion, and likely performs better too.
   
   _Originally posted by @scovich in 
https://github.com/apache/arrow-rs/pull/7935#discussion_r2220127481_
   
   **Describe the solution you'd like**
   <!--
   A clear and concise description of what you want to happen.
   -->
   
   Avoid the seperation of header size calculation logic and splice action
   
   **Describe alternatives you've considered**
   <!--
   A clear and concise description of any alternative solutions or features 
you've considered.
   -->
   
   **Additional context**
   <!--
   Add any other context or screenshots about the feature request here.
   -->
   


-- 
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]

Reply via email to