There's nothing wrong with the code you've shown, but where will you get
rid of the rows and thereby all the cells that you've created? The jvm
will keep all the objects in the heap as long as a reference exits. All
your cells will exist as long as the row exists as the references are
stored in the row.
No matter what you do, you're going to wind up with all the cells of the
spreadsheet in the heap. What you want to avoid is having multiple
copies of each cell. This method should be pretty good as the cell
object is only referenced in the row object.
Classic RPG has no way of communicating to the GC that it no longer
holds an object reference. So avoid using object references in your RPG.
That may be hard to do. It is very likely that your RPG holds a
reference to the Sheet, the Sheet holds references to all the Rows and
each Row holds references to all the Cells. You may not be able to drop
the reference from RPG to the Sheet without ending the *job* running the
program (also, thereby, ending the JVM).
Check the archives on this list and some of the documentation. RPG did
come up with a way to drop those references, but it is a little obscure.
Your dump shows 4 sheets, 30,000 rows, and 725,000 cells. Check the POI
methods. There may be a way to clear a sheet rather than making a new
one.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx
Sent: Wednesday, March 31, 2010 7:34 AM
To: java400-l@xxxxxxxxxxxx
Subject: HSSF POI performance improvement with Java helper routine
bugged
I've developed the following Java code, to reduce the number of call I
make from RPG via JNI to the HSSF POI API's that I use to generate large
spreadsheets. I've seen incredible performance gains, however, when a
spreadsheet got particularly large, I started getting Java dumps. I
suspect that I may be leaking objects due to my being a Java newbie, and
was hoping someone might see my error. I'm posting the Java code, and
then the RPG prototypes used to initiate the code. Thank you in
advance, and you're certainly welcome to use the code if you find it
useful.
// The two routines within this program are intended to replace the
hssf_text and hssf_num // routines in the HSSFR4 service program. Since
they execute all the small commands in // native java, with no objects
created to RPG, it seems to improve performance // dramatically, perhaps
either through better memory management, or fewer external calls to the
JVM.
// Using these routines also seems to improve temporary storage used in
the calling program as well.
package cellutil;
import org.apache.poi.hssf.usermodel.HSSFCell;
import org.apache.poi.hssf.usermodel.HSSFCellStyle;
import org.apache.poi.hssf.usermodel.HSSFRow;
import org.apache.poi.hssf.usermodel.HSSFRichTextString;
public final class newcell {
public static void Text(HSSFRow row, int col, byte[] array,
HSSFCellStyle style ) {
HSSFCell cell = row.createCell(col);
cell.setCellType(1);
String value=new String(array);
cell.setCellValue(new HSSFRichTextString(value));
cell.setCellStyle(style);
}
public static void Num(HSSFRow row, int col, double value,
HSSFCellStyle style ) {
HSSFCell cell = row.createCell(col);
cell.setCellType(0);
cell.setCellValue(value);
cell.setCellStyle(style);
}
}
D hssf_textz...
D PR static EXTPROC(*JAVA
D :'cellutil.newcell'
D :'Text')
D peRow like(HSSFRow)
D peCol like(jint) value
D peString 128 varying const
D peStyle like(HSSFCellStyle)
D hssf_numz...
D PR static EXTPROC(*JAVA
D :'cellutil.newcell'
D :'Num')
D peRow like(HSSFRow)
D peCol like(jint) value
D peValue 8f value
D peStyle like(HSSFCellStyle)
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
