We are using Aspose.PDF for .NET (v25.6.1) in a .NET 8.0 application to generate large PDF reports that contain a significant number of images (100+), along with text content.
While generating the report, we observed that the memory usage grows beyond 1 GB.
To optimize, we attempted splitting the report into multiple section-wise PDF files and then merging them into a final single PDF. However, even after explicitly disposing the objects after each section PDF creation, the memory usage does not reduce.
This leads to continuous high memory consumption (>1 GB), eventually causing performance degradation and risks of hitting memory limits and bringing the App pool down.
Expectation:
Memory usage should be released after disposing intermediate PDF documents during section-wise generation.
The overall process should allow generating large reports without excessive memory consumption.
Issue:
Memory remains consistently high even after disposing section-level PDF objects.
This behavior prevents efficient handling of large reports.
Environment Details:
Environment information
• Aspose.PDF for .NET Version: 25.6.1
• .NET Core: 8.0
• Content: ~100 (high quality) images + text
• PDF file size - 25.3 mb
Additionally we have also tried on latest Aspose version 26.2.0 but still the memory problem persists
Please Suggest on following points:
• Whether this is a known memory management issue with Aspose.PDF.
• Recommended best practices for handling large PDF generation with many images.
Any configuration, API usage patterns, or workarounds to ensure memory is released properly after disposing intermediate documents.
I have attached code snippet for your reference.
Code snippet.pdf (35.5 KB)
@psuryavanshiagy
Thanks for the sample file(s); that should help with reproduction. I have not confirmed this yet and can only confirm it after reproducing on our side. I need a bit more information to diagnose the performance issue in Aspose.PDF when converting pdf to unknown.
- How are the images loaded and added to the PDF (file path, stream, byte array, etc.)?
- After each section, are you wrapping the
Document, pages, and image objects in using blocks or calling Dispose() on every Aspose object you create?
- Which
Save overload are you using (file path, Stream, etc.) and do you set any PdfSaveOptions such as OptimizeImage or MemoryOptimization?
A support engineer will review your answers and follow up in this thread.
I’ll try to reproduce this using your samples. If I can confirm it, I’ll log it internally and follow up here.
A support engineer will follow up in this thread if needed.
@psuryavanshiagy
We have checked your code snippet and looks like you are using Aspose.HTML mainly. We did not see any conversion or loading method from Aspose.PDF perspective. Additionally, could you please share your sample HTML in .zip format with us? We will test the scenario in our environment and address it accordingly.
Code and Html.zip (20.5 KB)
We have shared the html file as well as the updated console app code that generates the aspose PDF in the attached zip file . You just have to update file paths correctly while using it.
We have also used pdfdoc.FreeMemory() method and also tried with latest versions of Aspose. Still the memory usage is very high.
@psuryavanshiagy
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): PDFNET-61787
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.