PDA

View Full Version : memory issue between 0.7.0 and 0.7.2



Anonymous
05-30-2002, 11:47 AM
we created a tabledata with 200,000 rows and use the demo application to run it. For version 0.7.0 it ran through without any problem but for version 0.7.2 I got the out of memory error. We tried to use the jave profiler to narrow down where the memory is comsumed without getting garbage collected but still could not get to the exact point. Can anyone explain the difference between these two version?

Anonymous
05-30-2002, 01:06 PM
Oh, this is evil. I wrote a small dataset of 120.000 records (SampleData5 in the cvs), and there were no increase in memory. OK, the system was awfully slow (is fixed now), but I wasn't able to see signs of a leak.
The generated report had 2008 pages.

So I think I need more data :)
How do you generate you data (from database?, calculated?). Could you send me the structure of your tablemodel (or if it is completly calculated it would be cool if you could send the complete model), so that I can do more testing on that?

Next question: On which target did you print? Or did the preview frame die on previewing the report?

To your questions on the differences beween the two versions:
- The reportstate is now an object, and state transition is done by creating a new state with the advance function. The states are only stored on page boundries (this is the same behaviour as in 0.7.0).
- Reports are paginated before they are printed.
- PDF stores the used truetype fonts if the target uses embedded fonts.
- All text elements perform a linebreak (here was a performance bottle neck, this is fixed and increases speed by factor 10, but this does not alter the memory allocation behaviour)
- ImageSupport for wmf-files has been added
- All elements got their complex constructors removed and getter/setter function for all properties were added.
- A report is now always completly initialized, which made reportprocessing easier.

But these changes seem not to alter the memory behaviour.

By the way, you are asking for 0.7.2, but the current release is the cvs version (an almost complete 0.7.3, just more testing and more documentation).

I also don't have a clue on this memory issue, but when you send me just a little bit more explainations and data, we will find the reason and fix it.

Have more fun,
said Thomas

Anonymous
05-30-2002, 05:04 PM
So I think I need more data :)
How do you generate you data (from database?, calculated?). Could you send me the structure of your tablemodel (or if it is completly calculated it would be cool if you could send the complete model), so that I can do more testing on that?
Ans: we used the SampleData2 and the following code to provide the actual data...
//
data = new Object[200000][5];
Integer number = null;

for(int i = 0; i < 200000; i++)
{
number = new Integer(i);
data[i] = new Object[] { "One"+ number.toString(), "Red"+ number.toString(), "A"+ number.toString(), new Integer(1), new Double(1.1) };
}
//

Next question: On which target did you print? Or did the preview frame die on previewing the report?
Ans: it dies on preview frame.

Actually, sometimes you have to run the preview frame 5 or 6 times to get the out of memory error on version 0.7.2 with the above data.

Now, we found that setFunctions in the ReportState.java
//
public void setFunctions (FunctionCollection pfunctions)
{
if (pfunctions == null)
{
throw new NullPointerException ("Empty function collection?");
}
else
{
functions = (FunctionCollection) pfunctions.clone ();
addReportListener(functions);
}
}
//

if I remove the clone() from "functions = (FunctionCollection) pfunctions.clone ();" statement, that is, "functions = (FunctionCollection) pfunctions;" then I don't get the out of memory error after I run the same preview frame with above data more than 10 times.

Anonymous
05-31-2002, 08:31 AM
I'm working on that issue.

So far I found out, that when you don't use the PreviewFrame, and print whole report by using the JFreeReport.printReport() function, you will not get any growing memory at all.

Try this one to see the result:

public static void main (String[] args)
{
// Log.addTarget(new SystemOutLogTarget ());
if (args.length < 1)
{
}

try
{
URL url = Log.class.getResource("/com/jrefinery/report/demo/report2.xml");

JFreeReport report = ReportGenerator.getInstance().parseReport(url);
report.setData(new SampleData6());

// set LandScape
Paper paper = new Paper ();
// This is A4 format
paper.setSize (595.275590551181d, 419.5275590551181);
paper.setImageableArea (70.86614173228338, 70.86614173228347, 453.54330708661416, 277.8236220472441);

PageFormat format = new PageFormat ();
format.setOrientation (PageFormat.PORTRAIT);
format.setPaper (paper);

long start = System.currentTimeMillis();
G2OutputTarget t = new G2OutputTarget(G2OutputTarget.createEmptyGraphics(), format);

for (int i = 0; i < 15; i++)
{
report.processReport(t);
System.out.println("Time: " + (System.currentTimeMillis() - start));
System.out.println("TotalMem: " + Runtime.getRuntime().totalMemory());
}
}
catch (Exception e)
{
System.out.println (e.getMessage ());
}
}

After 15 times, the memory usage is still stable, you can also write the result to pdf, but this will create huge files. Currently I'm going to believe that the ReportFrame or PreviewPane could cause the trouble, this is the next I'll check to track this strange thing down.

I've also seen, that a 1000 pages and more report is not funny to scroll through. I'll add a GotoPage box to the preview Pane today.

While writing the report to pfd, I also saw that printing was cruelfully slow. LineBreak caused this trouble and got a small change which increases speed for printing text by factor 10.

Have more fun,
said Thomas

Anonymous
05-31-2002, 02:19 PM
Yeah! Problem solved.

The evil reportstate was the one. The innerclasses of the state were not static and so every state created carries (hidden, unreachable) reference to the last report state. Arrgh, I didn't even know that such a thing exists - until now. After declaring all inner classes to be static, I paginated a report, with your table model and 500.000 rows. The total memory after paginating was roughly about 15 MB, but a reference of every completed page is stored in the paginating list.

This list is a result of this problem, I implements a weak reference binding between ReportStates of a certain page and the complete report. Missing or garbagecollected states get restored from failback points (every 10th element in the list).

I haven't tested it yet, but I think even some million pages won't be a problem for JFR anymore.

Now I check whether my PDF Viewer can handle a 200.000 pages pdf :)
The speed is not yet funny, this is the next point to be improved...

Have more fun,

said Thomas

Anonymous
05-31-2002, 03:35 PM
Good job, man. I will check it out this weekend.

Anonymous
05-31-2002, 06:01 PM
Taqua wrote:
> I haven't tested it yet, but I think even some million pages
> won't be a problem for JFR anymore.

But my printer only takes about 50 pages of paper in the feeder...

DG.