Let's not turn this thread into a benchmark frenzy, please.

The generated machine-code depends greatly on the JIT and can't really be predicted.

Sometimes FloatBuffers perform like float-arrays, sometimes they perform 10 times worse... let me show you what I mean:

Testing all 4 types of access:



Testing 3 types of access (all minus floatbuffer (float[]) )



So code in other methods doing other things, affects performance in appearantly unrelated code!



When invoking this anywhere:
FloatBuffer.allocate(elements);
the code using DirectFloatBuffer drops performance by factor 7-8

Probably because the JIT notices FloatBuffer now has more than 1 active subclass, so it can't optimize the general FloatBuffer class as it would do when only having DirectFloatBuffers around.

Life is better after 6 

the reason for unsafedemo being slower is that i use a "naked" unsafe instance. benchy extracts it from a bytebuffer.
if i use a bytebuffer's Unsafe, unsafe.get/put & arrays are almost equally fast. Unsafe is a bit faster, but you could have trouble avoiding the "base + (index<<bytes_of_type)"-calculation when accessing the buffer. if you can avoid it, Unsafe is the way to go

Does the JVM do bounds-check removal on Buffer types? I know i does on arrays..

Only the server VM does bounds check hoisting, AFAIK.

Cas

i'd say: no. a bytebuffer's get and put methods are always a bit slower than direct array accesses. (at least the last 10 times i looked at the results)
if i simply call a bytebuffer's private put/get-methods (jdk hack) which don't do bounds checks manually, i'm almost at array speed (50% slower). if i inline the calls and access the unsafe object directly, using (base+(offset<<2)) as the address to get an int, i'm really almost at array speed (up to 10% difference, sometimes faster, sometimes slower, which means it's pretty equal). using any precalucated value as an address speeds things up, and i'm at 200% array speed.
i assume this means:
a) java uses the same calculation to access random values in arrays
b) java doesn't do array bounds checks if the vm can be sure that no evil index will be used.