Re: NIO not so hot
On 17.05.2014 13:28, Roedy Green wrote:
I did a benchmark to read a file of bytes in one I/O then convert it
to a String
// Using a random sample data file of 419,430,400 chars
419,430,400 bytes UTF-8.
// RandomAccess 1.46 seconds
// InputStream 1.48 seconds
// NIO 1.56 seconds
NIO is great for grabbing bytes, but if you have to suck them out of
the buffer, it does a get() call on every byte.
This is not true for all cases. For example, if ByteBuffer and
CharBuffer have an array this method is invoked, which will directly
access these arrays:
sun.nio.cs.UTF_8.Decoder.decodeArrayLoop(ByteBuffer, CharBuffer)
The code is posted at http://mindprod.com/jgloss/nio.html
The code suffers from too much copying: in readFileAtOnceWithNIO() you
use a direct buffer, then need to copy it into a byte[] (which btw. does
not use individual get() for every byte, see
java.nio.DirectByteBuffer.get(byte[], int, int)) and then you create the
String (which copies the data again but that cannot be avoided). If you
use a heap byte buffer one level of copying can be omitted, because you
can access the byte[] inside and create the String with this constructor:
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String(byte[],
int, int)
However, the test is quite unrealistic since this is not how NIO is
usually used. The whole purpose of Buffer and subclasses is to read
data in chunks.
I have extended the recent test case for char decoding to include NIO.
Because NIO character decoding I created a version which does a rough
CRC calculation so I was able to verify my implementation read all the
characters in the proper order. You can find all the code here:
https://gist.github.com/rklemme/fad399b5e7cc4d3b6d0c
Kind regards
robert