JNI performance using SWIG

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown JNI performance using SWIG

by Mike Margozzi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

We are investigating SWIG for use in a project.
 
We want to create an object oriented interface that can be used by C++ clients
and also by Java clients. The most basic question at this point is this:
 
Assume we have a class Foo that has several class variables.
 
Foo {
    int prop1;
    int prop2;
    String prop3;
    String prop4;
 
    void update();
}
 
And it has getter and setters for each property. In addition it has an update() method. 
The update method is meant to commit the changes on the back end C++ side. 
 
We are concerned about the number of JNI calls that might be made.
 
The Java Client has a reference to a Foo instance, and wants to change all 4 properties
and commit the changes on the C++ side. So the client calls all 4 setters and then calls update()
to commit them on the C++ side. The way we have read the documents, this will generate
5 JNI calls. Is it possible to have the setters only modify the Java object locally and the
update method would pass all the properties in one JNI call? Are there directives to accomplish this?
 
Also, if a Java call will return a new Foo object:
Foo myFoo = Bar.getFoo();
Will a fully populated Foo be available? Or, will each getter cause an additional JNI call?
 
Are we worrying to much about the number of JNI calls? 
This article makes it seem 20 to 100 times slower than a Java method invocation. Is that true?
 
I am assuming you have had these types  questions before, so what do you recommend as a best practice
for this type of situation? I tried to search the mailing list archives, but was not able to find anything on the topic.
 
Mike Margozzi
 
 

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

Re: JNI performance using SWIG

by wsfulton :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mike Margozzi wrote:

> We are investigating SWIG for use in a project.
>  
> We want to create an object oriented interface that can be used by C++
> clients
> and also by Java clients. The most basic question at this point is this:
>  
> Assume we have a class Foo that has several class variables.
>  
> Foo {
>     int prop1;
>     int prop2;
>     String prop3;
>     String prop4;
>  
>     void update();
> }
>  
> And it has getter and setters for each property. In addition it has an
> update() method.
> The update method is meant to commit the changes on the back end C++ side.
>  
> We are concerned about the number of JNI calls that might be made.
>  
> The Java Client has a reference to a Foo instance, and wants to change
> all 4 properties
> and commit the changes on the C++ side. So the client calls all 4
> setters and then calls update()
> to commit them on the C++ side. The way we have read the documents, this
> will generate
> 5 JNI calls. Is it possible to have the setters only modify the Java
> object locally and the
> update method would pass all the properties in one JNI call? Are there
> directives to accomplish this?
>  
> Also, if a Java call will return a new Foo object:
> Foo myFoo = Bar.getFoo();
> Will a fully populated Foo be available? Or, will each getter cause an
> additional JNI call?
The Java myFoo is just a proxy instance of the underlying C++ object. I
suggest you run the simplest of examples, eg Examples/java/class and
take a look at the code.

>  
> Are we worrying to much about the number of JNI calls?
> This article makes it seem 20 to 100 times slower than a Java method
> invocation. Is that true?
> http://weblogs.java.net/blog/mlam/archive/2006/12/beware_of_the_n.html 
>  
This really depends on your usage. If you profiling finds that you have
a JNI overhead, then recode accordingly. The article's advice is sound
though and if you can avoid native calls, then do so. But as you are
considering using SWIG the assumption must be that you have a body of
C++ code that you do not want to rewrite in Java, therefore the trade
off is the JNI overhead.

> I am assuming you have had these types  questions before, so what do you
> recommend as a best practice
> for this type of situation? I tried to search the mailing list archives,
> but was not able to find anything on the topic.
>  

SWIG is designed to update the real object (the C++ object), not cache
some values in Java and then have an update method to move the values
from Java into C++. If you want to customise the generated code, take a
look at the javacode typemap which allows you to add pure Java code to
any Java proxy class.

William

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user