Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JNI - likeley bottlnec?  RSS feed

 
Ken Stubbings
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi I have a Specific question regarding JNI. Is there a delay associated with JNI calls? is this delay in the order of magnitued of 3ms (millis)?

This question is related to my post here.

Thanks you in advance JNI people.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ken-

Welcome to JavaRanch.

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it - please adjust it accordingly, which you can do right here. Thanks for your prompt attention to this matter.

Enyoy your time here.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't remember the exact timing, but yes there is a definite overhead to JNI. Broad rule of thumb is to use a small number of calls to do big amounts of non-Java work, not large numbers of calls for little things. A fair bit of argument shuffling has to be done as you go in and out of JNI. Recent JVMs are better than really old ones, but there is still overhead.
 
Ken Stubbings
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ulf Dittmer:
Hello Ken-

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it


Actually I did notice that, after glancing at it I decided that "Ken" did comply to the naming convention (being my real name and all). After reading your responce and analysing the naming convention, I am guessing that first names are not what you had in mind. You should state this more clearly in the "Official policy on registered names" as it would probabloy save you some time.

That being said, it is impressive to see that this forum is monitored so closely, and I expect to visit more oftern in the future, thanks.
 
Ken Stubbings
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reid M. Pinchback:
I don't remember the exact timing, but yes there is a definite overhead to JNI. Broad rule of thumb is to use a small number of calls to do big amounts of non-Java work, not large numbers of calls for little things. A fair bit of argument shuffling has to be done as you go in and out of JNI. Recent JVMs are better than really old ones, but there is still overhead.


Thanks v. much for your reply, that is pretty much what I guessed(/feard). If there is anyone who knows what sort of values (just an order of magnitued would be enough) one might be talking about for the delays, that would be really helpful. (I know java programmers arn't intresed in exact delay times, and neither am I, we just have this one rogue timing requirement :roll: )
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 15861
81
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think it is possible to say in absolute terms how long the delay is that you get with a JNI call - i.e., you can't say it is always 3 milliseconds or something like that.

How fast your application runs depends very much on the hardware and operating system you're running it on and the JVM version that you're using.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you just need crude numbers for a thought experiment-like estimate of what you getting into, I'd use 1/100th of a second for the overhead for recent JVMs. The first invocation would be much worse because the DLL must be loaded, but after that the overhead is largely determined by how much data type translation goes on in both directions. In practice I don't think you'll see 1/100th of a second because your native code is going to be doing something more interesting than nothing. As a data point, I've used JNI to access a native communications DLL for a remote system. The cost of doing a JNI call and a login was generally about 2/10ths of a second on a typical Windows desktop box, and the complexity of the login interaction would have been comparable to digested password exchanges.
 
Ken Stubbings
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again for your responces, I understand that timing is not something that one tends to worry about as a java programmer. I have had a few updates on my end; it seems that JNI is not the source of the bottleneck at all. The problem was with the USB device that the JNI was calling, however I am concerned now at Reids esimate at 1/100th of a seccond overhead per JNI call.
We had it down to 8ms between updates, and this is entirly explained away by the usb problems. Are JNI calls non-blocking? could the data we are getting back be delayed?

In any case this problem is starting to take on a new form, as it has come to my attention that 10ms is entering into the relm of serious realtime perfomance. The sort of thing that is not achivable (consitently at least) with standard pc hardware and operating systems. I think we may have to have a chat with the customer.

thanks again,
Ken
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Emphasis on CRUDE CRUDE CRUDE estimate. It entirely depends on a lot of factors and also on what constitutes good or bad delay for you (e.g. in my case 2/10ths of a second to do a secure login across a WAN to get a connection that would be re-used wasn't exactly slow). If you need to make a decision on accurate information, you need to do your own timings. A thought experiemnt is just that; a quick-and-dirty way to see if you are facing seconds versus hours versus years in time. Fundametally my point was simply that if you depend on using JNI in a way that only works if you have zilch in the way of overhead, you are probably need to re-think the granularity of the interaction. If you also want a cross-platform solution, you have to test the timing and functionality on each platform because the native-versus-Java coordination sometimes involves some form of OS-level signalling.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!