Improving perf of FileChannel.transferTo() on Windows

[David M. Lloyd]

On 10/15/2014 11:40 AM, Kirk Shoop (MS OPEN TECH) wrote:
> *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com]
>
> There have been attempts in the past to use TransmitFile but they ran
> into a number of issues, I think it was mostly semantics differences
> compared to sendfile. It was a long time ago but I think one example was
> sending HTTP headers via write following by the HTTP body with
> transferTo. If I recall correctly then TransmitFile bypassed the socket
> buffer. Do you anything about that?
>
> 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?

Maybe if flush is a non-blocking operation (I have no idea), if the 
operation would block, it could just cause the transferTo to return 0, 
or it could fall back to copying the data through buffers?


-- 
- DML