<div dir="ltr">Ah, I didn't realize that there was negligible overhead for wrapping as a buffer<div><br><div>That makes sense, so you're just allocating a single Object wrapping a zero-copy slice of the underlying buffer essentially?</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 9, 2022 at 9:58 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Gavin,<br>
for now we have no plans to provide I/O APIs to take memory segments <br>
instead of buffers.<br>
<br>
When working with I/O it is preferrable to map the segment into a buffer <br>
(which is a very cheap operation, no copy is required, only a view is <br>
created).<br>
<br>
Maurizio<br>
<br>
On 09/09/2022 14:46, Gavin Ray wrote:<br>
> We can see in the JavaDoc for FileChannel that "transferTo/From" is <br>
> the way to use potentially optimal I/O transfers<br>
> This requires a Readable/Writeable/SeekableByteChannel, which have <br>
> "ByteBuffer" as the argument types<br>
><br>
> Are there any plans to eventually modify I/O API's to take raw <br>
> MemorySegment's for better performance?<br>
> Or should folks just do MemorySegment.ofBuffer() etc?<br>
><br>
</blockquote></div>