Selon Ivan <[email protected]>: 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 > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
