On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <github.com+1701815+mk...@openjdk.org> wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for >> `Channels.newInputStream().transferTo()` which provide superior performance >> compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading >> to deeper levels via NIO, hence allowing the operating system to optimize >> the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still >> only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern >> hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this >> implementation, and (depending on the used hardware and use case) >> performance change was approx. doubled performance. So this PoC proofs that >> it makes sense to finalize this work and turn it into an actual OpenJDK >> contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of >> `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual >> review? > > Markus KARG has updated the pull request incrementally with two additional > commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel > Does it make **any** real sense to answer your recent questions, provide the > proofs, tests and benchmark results (I actually would love to _if_ it makes > sense) _or_ will the outcome be that I _must_ drop everything besides file > channels _anyways_ (In that case it is in vain)? As my time is just as > precious as yours I really need to know that **before** I spend more weeks > into code paths that you possibly decided to never accept ever. Don't get me > wrong, if you see a chance to keep the code once I provided the answers I > will do that, but if you do not see that chance, please frankly and > unambiguously tell me **now**. Thanks. I think the best course of action is to reduce the scope of this PR to the file channel cases. There is no reason why future PRs can't build on this and add implementations for other channel types. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263
