Re: JNA performance
On 05/09/2011 09:34 AM, Roedy Green wrote:
On Mon, 09 May 2011 08:36:00 -0400, Lew<noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :
So you have access to his performance test results to know where his
bottleneck is? Amazing.
In one sense yes. All JNI programs that are pure glue have the same
problem. There is nothing else too them but the glue.
You raise a good point, several really.
While it is true that "premature optimization is the root of all evil", as
Knuth famously pronounced, there is optimization that is not premature.
Roedy's advice is sound because he addresses a well-known source of
bottlenecks generally, the communication across the boundary between the JVM
and native code. It's entirely appropriate to consider the impact of such a
predictable architectural constraint.
OTOH, appropriate responses to this constraint are very specific to the
particulars of the application. If the Java program initiates all contact
with native logic or data, for example, it might have a lot more control over
the frequency of contact and the granularity of activity per call. If contact
is rare, or only flows from the JVM to the native world without need for
reply, then the JNI impact might be nil. No "optimization" needed.
For use cases involving tight communication between native logic and Java
logic, the pendulum swings the other way. You'll need to be hyper-aware of
the issues around the link, not only for performance but for resource disposal
and many other matters. Thinking about performance during your architecture
moments is a good thing to do in this context.
For a great many applications, you should consider performance measurement.
This does not replace the kind of architectural planning or up-front wisdom
that Roedy suggests. It supplements your overall quality strategy. Profiles
and baseline throughput measurements help you understand which theoretical
bottlenecks actually present practical problems, and contrariwise. They also
help you decide which ones of the real bottlenecks are worth fixing. Some
might be outside program control, or already at optimum albeit disappointing
performance. Some might be a little slower than you really could do, but not
worth the expense or effort to improve slightly.
So do follow Roedy's advice - which I'll paraphrase as "consider the impact of
the slow communication gate between JVM and native code" - and welcome the
knowledge he gave, that that gate is a slow one.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg