 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
10 messages in net.java.dev.jna.usersRe: [jna-users] performance of derefe...| From | Sent On | Attachments |
|---|---|---|
| James Way | Nov 6, 2007 8:00 am | |
| Timothy Wall | Nov 13, 2007 1:00 pm | |
| Wayne Meissner | Nov 13, 2007 3:48 pm | |
| Duncan McGregor | Nov 13, 2007 4:10 pm | |
| Timothy Wall | Nov 14, 2007 5:34 am | |
| Timothy Wall | Nov 14, 2007 5:58 am | |
| Timothy Wall | Nov 14, 2007 11:23 am | |
| Duncan McGregor | Nov 14, 2007 12:49 pm | |
| Shawn Erickson | Nov 14, 2007 1:13 pm | |
| Wayne Meissner | Nov 26, 2007 8:15 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] performance of dereferencing c pointers in java | Actions... |
|---|---|---|
| From: | Wayne Meissner (wmei...@gmail.com) | |
| Date: | Nov 26, 2007 8:15:49 pm | |
| List: | net.java.dev.jna.users | |
I did some benchmarking on this, and some experimentation with alternatives.
JNA could speed up Pointer.getByte() and friends significantly by passing the Pointer.address value down directly.e.g. class Pointer { ... private native byte nativeGetByte(long address) public byte getByte(long offset) { return nativeGetByte(address + offset); }
At least on macosx 10.4 with java 1.5, that halved the overhead of getByte() and friends. Its not supposed to, as (*env)->GetLongField() is supposed to be fast, but it does. Java 6 might be a different story though.
ByteBuffer.get() is as much as 10x faster than Pointer.getByte() due to getting inlined by hotspot, but the overhead of creating a DirectByteBuffer (even using reflection instead of jumping through JNI) outweighs it for single writes.
On 14/11/2007, Wayne Meissner <wmei...@gmail.com> wrote:
Thats pretty much correct. For simple (and mostly one-off) accesses,
Pointer.set{Int,Long,Float,etc} is faster than
Pointer.getByteBuffer().put{Int,Long,
etc}
However, if you need to do a lot, or bulk transfers, then getting a ByteBuffer and using it multiple times can be faster - even faster than the bulk transfer operations in Pointer.
One caveat to be aware of - allocating a lot of direct ByteBuffers in a loop can be hazardous - they don't seem to get GC'd as quickly as Memory objects, so you can end up with a huge amount of memory used by the jvm.
On 14/11/2007, Timothy Wall <twal...@dev.java.net> wrote:
On Nov 6, 2007, at 11:00 AM, James Way wrote:
I'm using jna to pass a large array of data from a database to a fortran program. I implemented this by passing a Pointer to a java callback function from native code, and I was wandering how fast this was compared to jni, for instance. Also, is using pointer.setFloat() as fast as using a pointer.getDirectByteBuffer()?
I'd recommend profiling your scenario to see what performs better. Direct buffers have higher allocation/deallocation costs than com.sun.jna.Memory, and native code can access either faster than a java primitive array. Tweaking the memory from Java will probably depend on the specific circumstances, since both methods use a dedicated JNI call to do the write. Wayne Meissner did some profiling in this area, but I don't recall the results.