[gdal-dev] Re: JAVA API - Performance

[Even Rouault]

Selon Ivan <ivan.lucena at pmldnet.com>:

Ivan,

thanks for your testing (CC'ing the list as it is of general interest).
Actually, I also read on some sites that using ByteBuffer object versus regular
Java arrays is not always a win. Plus the fact that we must use a direct buffer
that has an extra allocation cost according to the Javadoc. So ByteBuffer might
be interesting if you just want to pass big arrays between native code, for
example if you read an array from a dataset and then write it to another one
without accessing it from the Java side. When you mention that accessing through
the byte[] array was faster, did you get it with the array() method instead ?
I'm wondering what the performance overhead of this call is.

As ByteBuffer is not at all a requirement for the interface with the native
code, it would be technically possible to add an alternative API that would use
the regular Java array types.

Would you mind opening an enhancement ticket about that ? Thanks

Even

> Even,
>
> I did some test with the GDAL Java API and some simple raster operations
> like the GDAL Proximity algorthm and I noticed that the performance while
> accessing pixels with <type>Buffer.get(i), <type>Buffer.put(i,value) is not
> as good as if you copy then to (or from) a "regular" array, like float[],
> double[], integer[] and byte[].
>
> The reason for that is obvious, get() and put() are funtion calls and
> contains a lot of code for range check.
>
> If I understand it correctly, ByteBuffer is the ideal or maybe the only
> way to get access to Buffers from C libraries thought a Java wrapper. But
> do you it would be possible to incapsulate the buffer conversion at the
> wrapper code so that users would be able to read and write direct to
> regular Java arrays?
>
> Just a suggestion,
>
> Ivan
>