Improving perf of FileChannel.transferTo() on Windows

[Alan Bateman]

On 15/10/2014 17:40, Kirk Shoop (MS OPEN TECH) wrote:
>
> That is good to know. I was not aware of that. Where can I look for 
> previous discussion of this?
>
> If TransmitFile does bypass the socket buffer, my first thought is 
> that doing a flush before calling TransmitFile would avoid the issue. 
> I do expect that forcing a flush would cause a perf issue. A 
> mitigation for that would be to only use the flush/transmitfile path 
> when the file to send is large enough to hide the cost of the flush. 
> This would require having access to the file size. Has this been tried 
> before?
>
>
I'll see if I can find anything, the discussion and tests using 
TransmitFile pre-date OpenJDK. Another issue (and it's a long time ago) 
is when the SocketChannel is configured non-blocking, I think we 
concluded at the time that TransmitFile wasn't really suited for this 
case because it works synchronous (blocking) or asynchronously 
(depending on OVERLAPPED structure). Maybe you've already thought about 
this case.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141015/76f37353/attachment.html>