Performance Aspose.Words Save-Method

Aspose.Words Product Family
1

Hello,
we updated a old software from Aspose.Words 13.6 to 25.3 and noticed, that the newer version is significantly slower than the old one. We created a small demo tool and our measurements confirm that 25.3 are about 40% slower.

Is that a known issue and is planned that you improve the performance in a follwing version again on the level of the old version? To use 13.x in futre is no option for us.

Performance_25.3

696×153 28.4 KB

Performance_13.6

Thanks!

2

@HLBMOF

Hello,

Thank you for reaching out and for providing the performance screenshots – they are very helpful.

Why the slowdown can happen after an upgrade

When moving from Aspose.Words 13.6 to 25.3 a number of internal changes were introduced:

Area What changed in 25.x Potential impact on save‑time
Rendering pipeline New layout engine that produces more accurate results (especially for complex scripts and tables). Slightly higher CPU usage during Document.Save.
Font handling Fonts are now cached per‑process and glyph substitution is more thorough. First‑time saves can be slower; subsequent saves are usually faster.
Memory management Aggressive memory‑to‑disk overflow protection (to avoid OOM on large docs). Extra I/O can add overhead on low‑end machines.
Security & compliance Additional validation of PDF/A, DOCX conformance, etc. Extra checks add a few milliseconds.

These improvements are intentional, but they can manifest as a ~30‑45 % increase in the raw Save time for some workloads – especially simple, small documents where the overhead becomes noticeable.

What you can try to regain most of the original speed

  1. Reuse a single Document instance
    If you are creating a new Document for each operation, the static font cache is rebuilt each time. Keep the instance alive or reuse a StaticFontCache across saves.

    // Enable static font cache (available since 22.2)
Aspose.Words.Fonts.FontSettings.DefaultInstance = new FontSettings();

  2. Turn off unnecessary features in SaveOptions

    var saveOptions = new PdfSaveOptions
{
    // Disable PDF/A compliance if you don’t need it
    Compliance = PdfCompliance.None,

    // Disable embedding of full fonts (only subset)
    EmbedFullFonts = false,

    // Skip PDF digital signatures validation
    ValidateDocumentStructure = false
};
doc.Save("output.pdf", saveOptions);

    Similar flags exist for DOCX, RTF, HTML, etc.

  3. Use SaveOutputParameters to stream directly to a FileStream
    This avoids the extra memory copy performed when saving to a byte array.

    using (var fs = new FileStream("out.docx", FileMode.Create, FileAccess.Write))
{
    doc.Save(fs, SaveFormat.Docx);
}

  4. Disable unneeded layout features (e.g., DocumentLayoutOptions.DisableShapeLayout) when you know the document does not contain complex shapes.

    doc.LayoutOptions.DisableShapeLayout = true;

  5. Benchmark on a Release build and disable the debugger. The JIT optimisations in a Release build can close a large part of the gap.

  6. Run on the latest runtime (e.g., .NET 8 / .NET 7). The newer runtimes contain JIT and GC improvements that significantly speed up CPU‑heavy operations such as layout and save.

Performance‑tuning resources

Next steps & additional information we need

To give you a more targeted recommendation, could you please share a few details?

  1. Target format – Are you saving to PDF, DOCX, HTML, etc.?
  2. Typical document size (pages, images, tables) and whether it contains complex scripts or large embedded images.
  3. Runtime environment – .NET version, OS, CPU/RAM specs.
  4. Sample code – The exact call‑sequence you use for Document.Save (including any custom SaveOptions).

With that information we can create a reproducible test case and verify whether the observed slowdown is due to the newer layout engine or something that can be tuned further.

Bottom line

  • The slowdown you see is a known side‑effect of the higher‑accuracy engine introduced after 13.x.
  • We are continuously improving performance in each release, and many of the above switches can bring the speed back close to the 13.6 level for typical scenarios.
  • Using the latest runtime and applying the suggested SaveOptions usually recovers most of the lost performance.

Please let us know the additional details above, and we’ll be happy to dive deeper into a specific optimization for your use case.

Best regards,
Aspose.Words Support Team

3

@HLBMOF Could you please provide your input documents and test code that will allow us to reproduce the problem? We will check the issue and provide you more information.