Using Aspose.Words to save docx template to PDF slows down over time

Hello Aspose Team,
I’d like some technical input concerning my Aspose.Words instances slowing down over time.

What are we doing:
We’re using Aspose.Words to generate a PDF from a .docx template.
This is done in a DotNet 7.0 application, packaged up into a container using Docker, built on a “mcr.microsoft.com/dotnet/aspnet:7.0” base, which is then hosted on an internal Kubernetes cluster for our applications to hit.
We’re using containers and deploying to Kubernetes because of its ability to scale to varying demands.

The .docx templates we’re using contain a bunch of keywords that are replaced with values from our underlying system and then it’s saved to a PDF.

What are we experiencing
We’re experiencing that the doc.Save() method gets slow over time. When we initially deploy the application each save will take around 1 -1.5 seconds but progressively over time it slows down. A few days later it takes 5-6 seconds to save the doc to PDF and then suddenly it will explode and the doc.Save() method will take several minutes.
At a certain point this starts causing the applications calling our API to timeout.

To try and debug this issue we’re currently running a version in our production environment that contains stopwatches to show us which part of the code exactly that’s slowing the whole thing down. It’s very clearly the doc.Save() method that gets increasingly slow over time.

Redeploying the container instantly solves the issue and the Save() method will take the initially 1-1.5 seconds again.

Right now, our workaround is to automatically redeploy the container using a Cron job. This is an unacceptable solution long term, which is why I’m looking for a solution to the issue.

Other things that might be nice to know
The data being input into the template is very uniform in its structure. It always contains names, addresses, blood pressure readings, and a lot of boolean values. Which means the progressively slower saves can’t realistically be attributed to the data being replaced into the template being different between the saved document instances.

Code
I’ve attached a shortened and redacted version of the PDFGenerator code. I hope the redactions don’t make the screenshot completely incomprehensible. The real code contains quite a few more builder subclasses that replace certain sections of the template but these shouldn’t impact performance as it’s the doc.Save() method that gets slow.

@plspao If possible, could you please create a simple console application that will allow us to reproduce the problem on our side? We did not observe such problem earlier. Does the problem occur with some particular document or with any document? Is the problem reproducible if run the process in a simple loop?