Aspose.PDF (21.4 versus 24.2) shows peak usage of 2.1GB and 5.6GB respectively

I would like to echo the urgency of a fix for this one, which was reported a while ago but is still awaiting resolution.

Running the same C# code in a profiler against 2 different versions of Aspose (21.4 versus 24.2) shows peak usage of 2.1GB and 5.6GB respectively.
v21.4.png (27.2 KB)

v24.2.png (28.5 KB)

The code we use pulls in various different file formats (JPEG, DOCX, PDF) into a single PDF. We can’t control the volume or variety of the files we’re combining. It’s noticeable on the version 21.4 run that memory usage has the peaks and troughs we would expect as documents are loaded or unloaded for combination whereas the 24.2 version is virtually all uphill.

This problem is stopping us deploying our code into the client’s Azure environment due to regular ‘out of memory’ errors.

@pjjonah66

Would you kindly provide some code snippet and sample files for our reference along with the details of your environment? We will try to replicate the issue in our environment and address it accordingly.

Hello Asad. The code doesn’t really lend itself to running in isolation as it relies heavily on multiple SQL server tables and BLOB storage read/writes. We have our own proprietary code to manage access to BLOB storage. We also run code through any HTML files we import to find/replace text fragments in there prior to pulling them into the PDF. The text we use for this also sits in the DB

@pjjonah66

May be you can please narrowed down the code snippet to the original issue and share some sample files with us to replicate with? This would help us in replicating the issue and address it accordingly.

Hello Asad.

If I get a chance to do something like this I will do. At the moment I’m having to concentrate on rolling back our code to use the version of Aspose we used to work with (ancient version 11.8.0.0, but with a maximum memory usage of 1.1GB for the process I outlined in this post) in order to get our client to accept a new release. Unfortunately, this version works fine but lacks the feature we upgraded for originally (ability to ignore ‘invalid font’ errors in some PDFs we try to pull in to the completed PDF).

@pjjonah66

We do understand your concerns and value them as well. However, we need some details for our reference that can help us in replicating the exact same issue in our environment in order to address it accordingly. Anyways, please take your time and share the requested details with us so that we can further proceed accordingly.