This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcj's IO performance vs blackdown JDK


Hi Bryce (and Tom),

>> I have written a lot of programs that process huge text files a line
>> at a time at my work that are 2 to three times slower running under 
>> gcj than running under
>> the JDK and I am pretty sure this I/O issue is the cause.
>>
>> run_benchmark uses Hashgen.java to generate a 100000 line text file 
>> with 1000
>> character lines.  On my machine (433 Mhz celeron dell laptop running 
>> slackware
>> linux 9.0), it takes the JDK 11.1 seconds to run line_count against 
>> the file
>> and it takes the gcj compiled version 34.6 seconds.
>
>Thanks Christopher, this is a useful test case. I suspect the problem 
>here is our horribly inefficient implementation of 
>BufferedReader.readLine(). Given that it is calling a synchronized 
>read() method in a loop for every character in the stream, I'm 
>surprised its only 3x slower! You might like to have a go at making a 
>more efficient implementation, or alternatively, file an "RFE" bug in 
>bugzilla.

This has gone unclaimed for awhile, so I started messing around with it.

Actually, the problem isn't with the read() method. Although the call
to it is synchronized, it gets called once and then the entire filled
contents of the buffer are used.

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. This got me from 33s to 23s on my P450/256M. (The JRE time is 15s.)
I'm able to get an additional 2s gain (10%) by implementing lineEnd() in CNI,
thereby presumably avoiding the bounds checking.

What should I do now?:

- nothing
- submot this patch as-is (with a ChangeLog)
- submit this patch with lineEnd() implemented in CNI, which would require
  a new .cc file, patching Makefile.am, etc.

P.S. I'd be able to avoid a native method for BufferedReader if we had a
general-purpose class using CNI to search within a character buffer for
a certain character or sequence.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]