What is the status of fixing nio Buffer performance?

Question

The performance of nio Buffers is very slow in comparison to primitive arrays. Does anyone know the status for getting this fixed? For performance sensitive code, Buffers are currently unacceptable.
Several Bugs were open regarding this issue, but they have all mysteriously been closed without resolution?
(Bug ID: 4411600, http://developer.java.sun.com/developer/bugParade/bugs/4411600.html)
Any insight would be appreciated.

Answer 1

Here are numbers using the code from the Bug reference I posted above.
(Bug ID: 4411600, http://developer.java.sun.com/developer/bugParade/bugs/4411600.html)
The only change I made was to the main() function so I could run tests multiple times to see if Hotspot would kick in at some point.
Here is the change I made. Replaced the original main() function with the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
public static void main(String[] args) {
for ( int x = 0; x < 5; x++ )
System.gc();
System.out.println();
System.out.println( ">>>> run #" + x );
run();
public static void run()
timeArray();
time("heap", ByteBuffer.allocate(SIZE));
time("direct", ByteBuffer.allocateDirect(SIZE));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Btw, I am running this under Win2k.
The results follow.
D:\dev\parse>java -server Bench3
run #0array 30
array rev 80
heap 51
heap rev 90
direct 601
direct rev 401
run #1array 40
array rev 40
heap 571
heap rev 661
direct 671
direct rev 290
run #2array 41
array rev 40
heap 550
heap rev 671
direct 591
direct rev 291
run #3array 40
array rev 50
heap 551
heap rev 661
direct 590
direct rev 300
run #4array 50
array rev 51
heap 561
heap rev 651
direct 581
direct rev 291
D:\dev\parse>java -client Bench3
run #0array 181
array rev 190
heap 380
heap rev 390
direct 791
direct rev 701
run #1array 180
array rev 180
heap 861
heap rev 802
direct 731
direct rev 711
run #2array 180
array rev 180
heap 1202
heap rev 721
direct 721
direct rev 971
run #3array 200
array rev 180
heap 741
heap rev 731
direct 861
direct rev 821
run #4array 180
array rev 210
heap 911
heap rev 721
direct 741
direct rev 741
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
But after taking a closer look at the code I realized that both the heap and direct buffers were being run through the same sum() and reverse() methods, so maybe Hotspot's inlining policy avoids keeping more than one specialized version of a function cached?
So I re-ran the benchmark, but only running time("heap"...) and time("direct",...) one at a time. I will not bother posting the numbers, but this time array, heap, and direct were all roughly equivalent.
So depending on the scenario, maybe it is not as bad as I though?
To try another variant, I replaced all calls to bb.get(j) with bb.get(), thinking this may be an opportunity for Buffer to be faster than array, since no start-of-buffer bounds check should be necessary (can only iterate forward).
But even running heap and direct separately, the test yielded slow numbers that suggest no inlining was performed again?
So I'm not sure what to think? I would like to use Buffers over primitive arrays, but I have no certainty of the performance characteristics of Buffers? They may run fast, or they may run very slow, depending on the scenario and which functions are used.
Here are the numbers after replacing calls bb.get(j) with bb.get().
D:\dev\parse>java -server Bench3
run #0array 41
array rev 80
heap 271
heap rev 381
run #1array 40
array rev 50
heap 231
heap rev 321
run #2array 40
array rev 40
heap 241
heap rev 321
run #3array 40
array rev 50
heap 231
heap rev 321
run #4array 40
array rev 40
heap 231
heap rev 320