Re: Calling java from RPG - how to increase performance

Larry,

As others have suggested, the best thing you could do for performance
is eliminate the RPG. The steps you outlined could be done completely in
Java. If you use a compiled stylesheet (XSLTC) it should speed up your
processing and you should also be able to start processing the
transformed results while the input is being transformed by piping the
output to your Sql statement reader and running them in separate
threads.

David Morris

>>> Larry_Ducie@xxxxxxxxxxx 05/18/05 1:54 PM >>>
Hi chaps,
 
I posted the following on the RPG forum and got a couple of responses,
but I
was advised to fire it at you chaps for more info. As a result of the
responses on the RPG forum I'm now using jt400Native.jar instead of
jt400.jar to get a little extra oomph, but I'm still not sure if I've
set
the JVM up with the right values to optimise my application -
basically, I'm
looking for some advice on what inputOpts I should set when starting
the JVM
using JNI. I'm not even sure what options there are! I'm even starting
to
question the idea of using JNI at all, as I'm not sure what overhead
each
RPG-to-Java call actually adds. It seems almost impossible to get any
banchmarks for this stuff. Any help on this would be most welcome. 
 
Anyway, here's the post... 
 
Hi,
 
I have written a RPG service program that transforms XML [using
transform
stylesheets (XSLT)] into SQL insert statements. These are then executed
over
the database on the iSeries.
 
To do this I utilise the Java Native Interface (JNI) to create and use
java
objects. Basically, I create a transformer object. I then pass the
object an
XML stream source to transform, and a stream result to hold the
transformed
data.
 
For each transformation (assuming the transformer object does not
change) I
have to create a new StreamSource object:
 
To create the stream source object from RPG I have to perform the
following
steps:
 
1) Create a String object from the XML file path. (RPG-to-Java)
2) Create a File object from the String. (RPG-to-Java)
3) Free the String object - no longer needed. (RPG-to-Java)
4) Create a StreamSource object from the File object. (RPG-to-Java)
5) Free the File object - no longer needed. (RPG-to-Java)
 
I create a StreamResult object for each job that runs this process, so
I
only perfrom the following once:
 
1) Create a String object from the result file path. (RPG-to-Java)
2) Create a File object from the String. (RPG-to-Java)
3) Free the String object - no longer needed. (RPG-to-Java)
4) Create a StreamResult object from the File object. (RPG-to-Java)
5) Free the File object - no longer needed. (RPG-to-Java)
 
Now, this all works fine - I'm just not sure it's running as fast as
it
could be - approx 0.2 seconds for each transformation. After a few
hundred
transformations it seems to slow down - could this be the Garbage
Collector?
I start the JVM manually using JNI (with version 1.4.2 set). I also set
the
classpath manually (using putenv). The XML file path is retrieved from
a
data queue, and the result file path is created by the program. All
RPG
object references are freed one-at-a-time, not by pushing/popping the
local
frame. 
 
So, what are the best ways to speed things up???
 
I've considered the following:
A) Create a custom java class that performs the conversions from file
path
to StreamSource/StreamResult and just call it with the two byte
arrays.
B) Allocate more memory to the JVM - what's the best size? What's the
default size?
C) Run the whole process in java - I could execute the SQL using JDBC.
(but
would that just be even slower???)
D) I've not compiled the XML jar files (Xerces.jar, Xalan.jar, etc)
because
I believe the JIT compilers are better than CRTJVAPGM. Is this true?
E) I've not copied and compiled jt400.jar to put in my classpath -
should I
need to?
 
Basically, does the JNI carry a large overhead? Should I minimise the
number
of RPG-to-Java calls by writing a custom class? Should I optimise the
java
environment by allocating memory or compiling objects? I need your
wise
words.
 
The program source is available if it helps. (We're running at V5R2M0)
 
Thanks
 
Larry Ducie