RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16]

Markus KARG duke at openjdk.org
Sun Dec 11 15:22:25 UTC 2022


On Sun, 11 Dec 2022 12:54:04 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Please keep this PR open; I will continune work on it soon.
>
>> @mkarg Do you have any benchmarks/results for the change?
> 
> @AlanBateman It needed several months, but finally I found the time to provide the requested performance numbers:
> 
> TransferToPerformance.inputStreamLoop    104857  thrpt   25  20557.862 ± 1539.845  ops/s
> TransferToPerformance.transferFrom       104857  thrpt   25  22093.131 ± 1178.483  ops/s
> 
> TransferToPerformance.inputStreamLoop   1048576  thrpt   25   2366.391 ±  189.846  ops/s
> TransferToPerformance.transferFrom      1048576  thrpt   25   2553.160 ±   43.617  ops/s
> 
> TransferToPerformance.inputStreamLoop  10485760  thrpt   25    197.128 ±    8.086  ops/s
> TransferToPerformance.transferFrom     10485760  thrpt   25    202.492 ±    6.436  ops/s
> 
> These numbers undoubtedly proof that `transferFrom` is *always faster* than `InputStream::transferTo`'s original loop, for *all* tested stream lengths.
> 
>> @mkarg I'm asking because FileChannel transferTo is implemented (where possible) on sendfile/equivalent so fast for the file -> socket and file -> file cases. The changes in this PR make use of FileChannel transferFrom so may not be significantly better than the default implementation.
> 
> @AlanBateman The existing cases only covered file-to-something, while the current PR optimizes the reverse something-to-file way. As the above numbers proof that (why ever) `transferFrom` is *always faster* than the original loop of `InputStream::transferTo`, I will continue work on this PR ASAP.

> @mkarg Please do not rebase or force-push to an active PR as it invalidates existing review comments.

Justification: I have updated this PR by rebasing the 8278268 branch ontop of the master branch. This was needed because the original code had merge conflicts, since it was originally authored ontop of JDK 18.

-------------

PR: https://git.openjdk.org/jdk/pull/6711


More information about the nio-dev mailing list