Enormous memory consumption

Hello,

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?

@YuriGubanov

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.

Thank you for the answer. May we have a trial for version 22.11 suitable to generate big reports?

@YuriGubanov

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.

Hello,

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.

@YuriGubanov

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.

We are sorry for the inconvenience.

Hello,

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.

@YuriGubanov

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.

We are sorry for the inconvenience.

Hello,

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).

@YuriGubanov

Below separate tickets have been logged in our issue tracking system for further investigation.

  • PDFNET-53209
  • PDFNET-53210
  • PDFNET-53211

We will look into their details and let you know once they are resolved. Please be patient and spare us some time.

We are sorry for the inconvenience.

The issues you found earlier (filed as PDFNET-53179) have been fixed in Aspose.PDF for .NET 23.1.

@YuriGubanov

Try to use the File parameter of the Image instance inside method GenerateDataTableRowWithPicture to set the file name of image, instead of use stream

Image asposeImage = new Image { FixHeight = 148, FixWidth = 128, HorizontalAlignment = align, File = PictureFilePath, Margin = cellMargin }; 

The issues you have found earlier (filed as PDFNET-53172) have been fixed in Aspose.PDF for .NET 23.2.

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.

@YuriGubanov

Would you please try with 23.2 version using streams? We have improved the API in this version. In case issue still occurs, please let us know.

The issues you have found earlier (filed as PDFNET-53209) have been fixed in Aspose.PDF for .NET 23.5.

Please specify if the issue PDFNET-53210 has been fixed. I see it closed, but it is not clear what was the reason for closing.

@YuriGubanov

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

Image asposeImage = new Image { FixHeight = 148, FixWidth = 128, HorizontalAlignment = align, File = **PictureFilePath**, Margin = cellMargin };