This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj's IO performance vs blackdown JDK
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, Christopher Marshall <christopherlmarshall at yahoo dot com>, java at gcc dot gnu dot org
- Date: Wed, 24 Dec 2003 08:21:14 -0600
- Subject: Re: gcj's IO performance vs blackdown JDK
- Reply-to: gnustuff at thisiscool dot com
Hi Per,
>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.
I'll try this.
>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.
I think it's because Christopher's test case is contrived in that
it operates on a test data file of 100000 lines of 1000 columns
each, which means that we frequently "wrap around".
Which brings me to my next question: what if we made buffer
circular?
>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.
Like Bryce, I looked in FileInputStream, but I didn't look long enough
to catch the 100 byte buffer thing.
Thanks for the other tips.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/