High Memory Usage and OOM Error while converting PDF to Postscript

Aspose.PDF Product Family
1

Hello, we are using aspose 26.5.

We have an application we are working to incorporate aspose into. It has a memory limit of 1028MB.

We have found that converting from PDF → .PS using the PSSaveOptions class produces an out of memory error heap error.

We have been testing with two documents, one around 12MB, the other 75MB. I have removed the memory limit from our application in local testing and see the usage in task manager reach 5-8GB.

here is the method that is causing the issues:

private void runPsConversion(String collatedDocPath, String psOutputFilePath) throws IOException {
    MemoryExtender.setSwapEnabled(true);
    MemoryExtender.isOptimizedMemoryStreamByDefault(true);
    try (com.aspose.pdf.Document collatedDoc = new com.aspose.pdf.Document(collatedDocPath)) {
        PsSaveOptions options = new PsSaveOptions();
        collatedDoc.save(psOutputFilePath, options);
    }
    MemoryExtender.isOptimizedMemoryStreamByDefault(false);
    MemoryExtender.setSwapEnabled(false);
}

We have tried a number of other memory saving methods, such as the optimization methods within the Document class, but those produce high memory usage as well.

Is there any recommendation for a low-memory usage implementation that we can use, while preserving high-quality outputs?

2

@phydesmith

Hi
the general recommendations are following:

  • Convert in batches instead of one save() over the whole file: open the source, copy a small page range (e.g. 5–10 pages) into a new Document, save that to its own .ps, dispose it, and repeat. This caps peak memory at one batch regardless of total document size.

  • Call options.setEmbedFont(false) when full font embedding isn’t required for the target RIP/printer — this removes the largest avoidable allocation.

  • Run the process as 64-bit with a headroom-sized heap, and dispose() each Document (your try-with-resources already does this) so batches don’t accumulate.

If a specific document still OOMs at a small batch size, send us that file — at that point it’s likely a single page with very large embedded images, and we’d handle it as a separate rendering issue.