<div dir="auto">I'm also looking forward to io_uring support on Linux kernels which support it and the Windows equivalent :-) The first one should come with one of the project Loom updates sometime.<div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto">Johannes</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Markus KARG <<a href="mailto:duke@openjdk.org">duke@openjdk.org</a>> schrieb am Sa., 24. Dez. 2022, 10:11:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.<br>
While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.<br>
Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.<br>
As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.<br>
<br>
One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.<br>
Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.<br>
<br>
Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:<br>
The small buffer clearly stands in the way of faster transfers.<br>
The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.<br>
Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.<br>
<br>
<br>
TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ± 47.057 ops/s<br>
TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ± 93.337 ops/s<br>
TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ± 89.555 ops/s<br>
TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ± 96.623 ops/s<br>
TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ± 40.798 ops/s<br>
<br>
<br>
Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.<br>
I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.<br>
<br>
Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.<br>
<br>
-------------<br>
<br>
Commit messages:<br>
 - JDK-8299336<br>
<br>
Changes: <a href="https://git.openjdk.org/jdk/pull/11783/files" rel="noreferrer noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/11783/files</a><br>
 Webrev: <a href="https://webrevs.openjdk.org/?repo=jdk&pr=11783&range=00" rel="noreferrer noreferrer" target="_blank">https://webrevs.openjdk.org/?repo=jdk&pr=11783&range=00</a><br>
  Issue: <a href="https://bugs.openjdk.org/browse/JDK-8299336" rel="noreferrer noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8299336</a><br>
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod<br>
  Patch: <a href="https://git.openjdk.org/jdk/pull/11783.diff" rel="noreferrer noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/11783.diff</a><br>
  Fetch: git fetch <a href="https://git.openjdk.org/jdk" rel="noreferrer noreferrer" target="_blank">https://git.openjdk.org/jdk</a> pull/11783/head:pull/11783<br>
<br>
PR: <a href="https://git.openjdk.org/jdk/pull/11783" rel="noreferrer noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/11783</a><br>
</blockquote></div>