We are generating quite a big PDF document using Aspose 21.8 (about 2300 pages). For every new page, we fill it with data, then call Document.Save(Stream) and Stream.Flush(), and then also close image streams for the page. Nevertheless, RAM consumption grows dramatically and peaks at more than 7Gb, though the total document size is less than 300 Mb.
Is there any way to cleanup memory during generation?
We request you please use the latest version i.e. Aspose.PDF for .NET 22.11 as it has a lot of improvement in terms of memory consumption. You can also use Document.FreeMemory(); method in order to release the memory once document is saved. In case issue still persists, please share a sample console application for our reference so that we can try to replicate the issue in our environment and address it accordingly.
You can simply upgrade API version using NuGet Package Manager and use a free 30-days temporary license in order to evaluate it. In case you face any issues, please share complete code snippet and sample files to replicate it. We will test the scenario in our environment and address it accordingly.
This simple sample would hang forever: https://1drv.ms/u/s!AkLThqAden-cgk2OpxLCLqR3ifp5?e=N4FQHI (solution for VS 2022 and .NET Framework 4.7.2). The folder “packages” with Aspose.Pdf 2021.8 inside is not included as it occupies about half a gigabyte. It should be restored manually.
Note that the report would be successfully created if FontSize is changed from 13 to 12 or 14. It seems that the engine has difficulties with splitting long words. The problem seems to be not fixed in Aspose.Pdf 2022.11.
An issue as PDFNET-53172 has been logged in our issue tracking system for further investigation on this case. We will look into its details and keep you posted with the status of its correction. Please be patient and spare us some time.
Here is another sample: https://1drv.ms/u/s!AkLThqAden-cgk5oisYO5bKBEucn?e=iHNZf6. It is almost the same as the previous one but reflects another issue: report generation crashes with “IndexOutOfRangeException” on a very simple string of 3 characters.
Another ticket as PDFNET-53179 has been logged in our issue tracking system for analysis against this new case. We will look into details of it too and keep you posted with the status of its correction. Please be patient and spare us some time.
Here is one more sample when Aspose hangs on call to “Save”: https://1drv.ms/u/s!AkLThqAden-cgk-LkQOKz8HCOxSn?e=Q1Igyi.
This time it is related to page break, i. e. the case when a new page is created manually. Hanging doesn’t occur when the second record is added to the same page and table as the first one, or when font size is changed from 13 to 12 or 14.
The 4th bug is here: https://1drv.ms/u/s!AkLThqAden-cglDAnZdnxs1jYFav?e=7vB1qA.
It was reproduced on the latest available version (22.11) with the trial license for PDF.NET. On the second step of the loop, Aspose crashes on saving with “System.ObjectDisposedException: ‘Cannot access a closed Stream.’”, though a new stream is created for every step.
https://1drv.ms/u/s!AkLThqAden-cglFJv63lsyBF_1o7?e=ivVgFC - this sample illustrates memory consumption. When built and started from the command prompt, it crashes with OutOfMemoryException at steps between 60 and 70 (a screenshot: https://1drv.ms/u/s!AkLThqAden-cglKVY-mAfvrkORHO?e=jcRzbT).
Unfortunately this is not suitable for our use cases. As our data sources are primarily disk and phone images (including compressed, encrypted, archived etc.), we do not use physical files but work with streams instead.
Please try to use the File parameter of the Image instance inside method GenerateDataTableRowWithPicture to set the file name of image, instead of use stream