RFR: 8292698: Improve performance of DataInputStream [v4]

Roger Riggs rriggs at openjdk.org
Wed Sep 14 22:04:47 UTC 2022


On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ± 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ± 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ± 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ± 0,087  us/op
>
> Сергей Цыпанов has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

The tests for endianess for DataInputStream are in the TCK and would have caught this case.
Tests for endianess are not duplicated in the jtreg test suite.

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

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


More information about the core-libs-dev mailing list