Reducing Java heap space consumption while PDF creation

Question

I've got a problem with iText.

I'm creating PDFs with lots of images, so the Java heap space runs out very easy.

Tried to analyze the dmp with Eclipse Memory Analyzer and found out, that every image uses about 10MB of heap space. But they have only about 350KB on the HD

Is there the chance to flush the heap to the HD and go on with the creation?

Are there other common leaks?

Unfortunately I found nothing useful yet.

That's what the heap looks like for one image

In general I think that added elements remain in cache... how can I get them out?

Is something like this possible?

That's the code as I use it at the time:

Document document = new Document();
PdfWriter writer = null;
        try {
            writer = PdfWriter.getInstance(document, new FileOutputStream(this.savePath));
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (DocumentException e) {
            e.printStackTrace();
        }

document.open();

Paragraph pdfTitle = new Paragraph();
pdfTitle.add(new Phrase("Title"));

try {
    document.add(pdfTitle);
    document.add(Chunk.NEWLINE);

} catch (DocumentException e) {
    e.printStackTrace();
}

for(int x = 0; x < 10; x++){
    //chapter
    Paragraph chapterName = new Paragraph("Chapter "+x, FONT[1]);
    ChapterAutoNumber chapter = new ChapterAutoNumber(chapterName);

    try {
    document.add(chapterhapter);
    } catch (DocumentException e) {
        e.printStackTrace();
    }

    for(int y = 0; y < 10; y++){
        //sec
        Paragraph sectionName = new Paragraph("Section "+y, FONT[2]);

        Section section  = chapter.addSection(sectionName);

        for(int z = 0; z < 10; z++){
            //subSec
            Section subSection = null;

            Image image = null;
            try {
            image = Image.getInstance(path);
            } catch (BadElementException e) {
                e.printStackTrace();
            } catch (MalformedURLException e) {
                e.printStackTrace();
            } catch (IOException e) {
                e.printStackTrace();
            }

            image.scalePercent(50);

            image.setCompressionLevel(9);
            Paragraph subDesc = new Paragraph("Desc "+z, FONT[3]);

            subSection = section.addSection(subDesc);

            picSection.add(image);

            try {
                document.add(subSection);
            } catch (DocumentException e) {
                e.printStackTrace();
            }

        }

    }

}

document.close();

Answer 1

I'm the original developer of iText, and I've downvoted your question because your code is all wrong.

For instance: you create a chapter object, but you're not adding it to the document ever. Instead you're adding a picSection object that isn't defined anywhere.

My main criticism however, is the fact that you're using the ChapterAutoNumber object, which implements the LargeElement interface, and complain about memory use. That's like saying: every day I eat a jar of mayonaise, I wonder: how come I'm so fat?

Why are you using Chapter/Section? If bookmarks are the main reason for choosing these objects, you should switch to using PdfOutline if you want to reduce the memory used. Because now, you're building up a huge pile of objects by adding them to the Chapter object, and these objects can only be released at the moment you add the chapter to the document. Before that moment, it's no use to do garbage collecting because the garbage collector can't throw away the content stored in the Chapter object.

If you are addicted to using the Chapter class, take a look at the setComplete() method, and add small portions of the chapter to the document on a regular basis, so that objects can be released little by little. The first approach (not using the Chapter class) is far better than this second one.

I may decide to remove the Chapter/Section classes from iText if I see more questions like this.

Answer 2

There are some useful answers here: Java heap space out of memory

Try setting the images to null after appending them to PDF?

Answer 3

My first guess would be to search iText documentation for some kind of streaming support. Is there some way not to store the whole PDF being created in memory? RTFM.

Second option is certainly to increase a heap size for your application, if you have an appropriated hardware for that.

And, just in case, I should mention a memory leak possibility. Although in your case it does seem unlikely, there is Plumbr if you need it :)

Answer 4

The reason the 100kB image takes up so much memory is probably because it is compressed on disk and uncompressed (raw) in memory.

Java should garbage collect and be able to work with this unless you use too many at the same time and you get out of memory.

This question goes into cleaning up the used memory; Java Heap Overflow, Forcing Garbage Collection

Sometimes re-using objects mitigates memory usage. Can you re-use the last PDF/Image object and load the next one into it. Meaning instead of creating a new object?