RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3]

[Markus KARG]

On Mon, 17 Apr 2023 19:07:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>...given that the intervals overlap by more than one third one must question the significance of the change.

I see your statistical point (BTW overlap of just one third *is* good enough for me, as it is definitively *not the same* performance), but we are not just statisticians we are also engineers, and share the knowledge that *not executing* code *will* always be faster than *executing* code (I think the only difference we have is that you expect *more* improvement). So given the fact that still there is *some* improvement (the statistics do not imply that there is *no* improvement, it only implies that it is *small*), I really, really would like to contribute this change, still. My points are:
* *Every single* spared CPU cycle is a good thing these days, even if the performance benefit is small for a *single* application, in the end this sums up to lots of spared CPU cycles when looking at the mere sum *all* applications on earth. In a mathematical sense: 1 * n still is n but not 0.
* As a result, the world spares not only CPU cycles, but also spares power consumption, and with this, produces less need for cooling, which in turn spares power consumption. So in the end, in sum we globally spare some tons of CO2 per years. Even if it is only very few tons, it is a benefit for the world climate, gained for rather free. So why *not* doing it?
* I see that we need to trade-off efforts, risk and benefit. For me, the effort from here to target is nearly zero, as the code is already done, is reviewed, is proven functional, and is test-covered. The additional risk of this PR is not much higher than the risk we accepted already with any other optimization we already did in the area of `transferTo` in the past years. For me, each single spared CPU cycle / each single spared ton of CO2 counts much, much more than anything else.

So I plea to accept this PR, even if not statistically evident! :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1584285102