Hey everyone,
We’ve come across another issue with the library, and we’re hoping you might have some insights!
While converting PDFs to Word, we noticed a major difference in memory usage between two NuGet packages: Spire.PDF and Spire.PDFfor.NETStandard.
Here’s what we found:
During development, we used Spire.PDF on a Windows 11 machine with 64GB RAM, and everything ran smoothly.
Since our product runs in a Docker container, we switched to Spire.PDFfor.NETStandard, as the standard version of Spire.PDF relies on native Windows functionality and doesn’t work inside Docker.
Initially, this worked fine on both Windows and macOS (16GB+ RAM) and inside our test Docker container.
However, once deployed in Azure Container Apps (2 vCPU, 4GB RAM), one of our clients tried exporting a 7-page PDF (with 10-15 images and some tables), and it crashed the server in seconds.
We investigated and found that Spire.PDFfor.NETStandard was consuming up to 6GB RAM for that document. Doubling the pages resulted in 12GB RAM usage consistently.
For comparison, switching back to Spire.PDF locally showed a much lower memory footprint—barely exceeding 2GB for the same PDF.
Testing with another PDF confirmed a similar trend: Spire.PDFfor.NETStandard used 2GB RAM, while Spire.PDF used only 200MB.
Since memory usage appears to scale linearly with the number of complex pages, simply increasing RAM isn’t a sustainable solution—some reports could be tens or even hundreds of pages.
We can’t share the exact PDF that caused the issue, but we’d love to hear if anyone has encountered a similar problem or has ideas on how to optimize this!
Best regards,
Ognjen