Re: gcj's IO performance vs blackdown JDK

[Per Bothner <per at bothner dot com>]

Mohan Embar wrote:

> In the code below, I got rid of the synchronization, but the major gain
> came from reusing the StringBuffer throughout the lifetime of the BufferedReader
> instance.

Well, first question is: how often do we get to the StringBuffer case,
as opposed the new String(buffer, pos, i - pos) case?  I would guess
that case is much more frequent, so we want to concentrate on that
first.

A optimization:  Use String.valueOf(char[], int, int) rather than
new String(char[], int, int).  The former allocates one object; the
latter allocates two objects.

On the other hand, the StringBuffer case is relatively frequent;
otherwise your changes wouldn't have made such a difference.  It
might be worthwhile trying to igure out why.

Note that a StringBuffer is just a char[] buffer and a length, plus some
helper methods which you don't need.  So you could easily replace
the StringBuffer with a char[].

Beyond that, you could combine the buffer field with the readLine
output buffer:  If the first lineEnd fails to find the end of the line,
do a System.arraycopy(buffer, pos, buffer, 0, limit-pos), and read
some more into the rest of the buffer.  If the "rest" of the buffer
is small, resize it - just as StringBuffer has to do when its buffer
is too small.

One issue to consider is this is that we may be reading misaligned
data.  If we could page-align the buffer we might do much better.
There we need to concentrate on the underlying FileInputStream.
It is important that this be properly buffered, and that the byte
buffer be page aligned.  This means that the byte buffer has to
be a raw page, rather than a Java array.

This should be done using java.nio, of course.

Apropos:  I notice that DirectByteBufferImpl allocates memory
using malloc.  Shouldn't it be using valloc instead?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/