We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Performance Degradation with export using Aspose.Words 19.9

We recently upgraded our Aspose (Aspose.Words for Java) version from 16.7 to 19.9 and noticing about 15-20% performance degradation in our export functionality. Profiler clearly shows that the Aspose calls are taking longer with the upgrade eventually causing reports exports on our application to timeout and fail. Is this a known issue? Are there any fixes expected to resolve this?


Have you also tried the latest version of Aspose.Words for Java i.e. 19.12 on your end? In case the problem still remains, please ZIP and attach your simplified input Word document you are getting this problem with and a simplified Java application (source code without compilation errors) here for testing. Please also share your OS and JDK versions and any other environment details which will help us to reproduce the same problem on our end. We will then investigate the issue on our end and provide you more information.

Hello Awais.

It appears there have been some performance degradations in the appendDocument method, which we use in several places. Because of some customizability with the merge field templates we provide we need to create many smaller Document objects and append them to a root document. We also use the method provided in this support thread to remove continuous section breaks that also uses appendDocument.

If there are ways to reduce our usage of appendDocument in favor of more performant methods that would be helpful, but we will still have some usages of it and need for its performance to be better, or at the very least not decrease like we’ve seen it.

I’ve attached a zip of an IntelliJ IDEA project with code that should show the slowdown. You just need to supply the Aspose jars of the appropriate versions. When using 16.7 the method takes around 74 seconds to run, and when using 19.12 it takes around 119 seconds, an approximately 60% increase. AsposeAppendDocumentIssue.zip (18.5 KB)

There may also be other performance degradations that are combining to affect our usage of Aspose. Are there any internal testing results you can share about the performance of various parts of Aspose Words over time that may help us locate issues?


We have logged your problem in our issue tracking system. Your ticket number is WORDSJAVA-2279. We will further look into the details of this problem and will keep you updated on the status of the linked issue. We apologize for your inconvenience.

Thank you Awais. I look forward to the results of your investigation.

Doing some further digging of our own into our performance issues we’ve noticed that the number of Ref objects in memory is quite large, outstripping everything else the server is doing. As you can see here there are 12.4 million Refs, with the second highest count being maps of Aspose Nodes.

Is this the expected behavior, because Aspose has to load all the Refs and Nodes in the document being generated? Or is there something we can do to free up those from memory once work in a portion of the document has been completed?


Thanks for the additional information. We have logged these details in our issue tracking system and will keep you posted here on further updates.

Is there an ETA on the fix for the issue reported (WORDSJAVA-2279)?

We downgraded to the older Aspose version as the performance with the new version was outside our product’s acceptable bounds. The upgrade license we invested in is basically unusable. Could you connect us with your Support Manager/Engineering Manager to discuss consulting service engagement for performance optimization using your recommended best practices? This is affecting some of our business timelines at our end and would appreciate a quick resolution.


I’m afraid, this issue is currently in analysis phase and we do not have any ETA yet. We’re trying to get an ETA for the resolution of this issue. We do not have a workaround for this issue yet either, so it would have to be fixed in the product itself.

If you’re interested to speed this up under paid support or paid consulting, one of our team members would be in touch with you to discuss further. Under free support, we need to manage issues on first come, first serve basis and there is only a limit to which we can expedite issues under free support. So let’s try to find out the ETA under current scenario and we’ll also get in touch with respect to alternative scenarios.

Thanks for your understanding.

We are not willing to invest in the Paid support or consulting while the full license upgrade cost in itself isn’t paying out to our advantage. We would like to get a refund of the product license in that case and will plan an upgrade when you are ready with the fix for this issue. Could you connect me to a support Manager or Sales Manager to help us with the refund process.


Please check: TestJava2279.zip (20.2 KB)

We now measured your code snippet using JMH and did not notice the difference on our end. Moreover, Aspose.Words for Java version 20.1 works slightly faster than 16.7.

We believe the only way to test this scenario properly is to use the JMH tool on your end. We created above demo project for you which helps to retrieve some numbers.

  1. Set up the license file
  2. Set up the path to the “newdocproblem.docx” file
  3. Choose the Aspose.Words version in pom.xml (get from Maven repository)
  4. Call .\run.bat
  5. Send back the two report files for further investigation

We also need more details on the environment you are performing these tests on e.g. please provide information on the OS, the exact JDK version, RAM, GC etc.

Another suggestion is to use the following settings for better performance of Garbage Collector:

-XX:NewRatio=3 - for Parallel Garbage Collector
-XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1HeapRegionSize=4m - for G1 Garbage Collector

We are also working on your above concerns and will get back to you soon.


I can understand your situation. We have already asked the team to provide an ETA for this. Also, please try to test this issue with version 20.1 as suggested by @awais.hafeez and provide the further details.

We would really like to help you out, but as you can understand some issues occur for certain specific scenarios and are also complex to deal with. Usually, these are not generic issues in nature, but relate to certain documents or environments.

However, if you’re still not happy after trying the latest version and working it out with our team and the ETA when available. You may further discuss your refund request with our business team: https://company.aspose.com/contact. Thanks for your cooperation and understanding.

Hello Awais,

We tried the benchmark we sent you with 20.1 and saw it take 104 seconds, which showed a small gain over 19.9, but that is still significantly slower than 16.7

We also ran your provided benchmark project.

To get the project to run:

  • We had to add the javax.annotation-api dependency to pom.xml
  • We had to use Aspose 16.7.0, as 16.7 does not exist in repository

The system used for the tests had this configuration:

  • OS architecture: amd64
  • Java VM name: OpenJDK 64-Bit Server VM
  • Java version: 11.0.2
  • Max Memory: 8126
  • Language Level: 1.8

Using your provided benchmark project and our machine we achieved these results:

JamaAsposeJava2279Test.zip (1.5 KB)

The average time for 16.7 was 5935 ms/op, while the average time for 20.1 was 6783 ms/op, showing a decrease in performance of 848 ms/op


Thank you for sharing further input on this topic. We have noted that you are observing ~13% performance degradation in your environment during 16.7 to 20.1 transition. Taking into account these new details that you shared in previous post, we will have a look at this task again and keep you posted on further updates.


It is to inform you that we are unable to observe creation of so many Ref instances on our end when running the source codes you shared with us so far.

Your screenshot indicates that 12,441,138 Ref instances are consuming ~200MB of memory on your end.

Can you please double check and confirm that too many Refs are being created on your end in the same scenario you provided us? Or perhaps, you may be seeing this picture during executing your real project. Or in case the above screenshot reflects the situation of some other scenario, then please provide a Demo Application that we can run to observe creation of so many Ref instances on our end. Thanks for your cooperation.

The previous image was from our test server running our full application. I have attached a zip file with a project that somewhat reproduces the issue. It isn’t as severe as in our full application which does more work to produce the export, but the test project follows the high-level flow of what happens.

Using 19.9 , profiling this project shows a large amount of Refs in memory.
image.png (27.3 KB)

Using 20.1, profiling the project shows that the number of Refs is much lower.
image.png (27.6 KB)

TestJava2279-Ref.zip (3.2 MB)

Does the 20.1 allocation seem more in-line with what should be expected with Aspose?

Unfortunately the way our system uses user-defined templates requires a lot of separate templates. The basic flow is that for a list of objects to be exported, we find the matching user-defined template, execute the mail-merge on that template with the object, then append that result onto the parent document until all the objects are appended to the parent document. In the profiling of the application it shows that the calls to appendDocument inside of removeContinuousSectionBreaks account for approx. 1/4 of the overall time to export a document. Is it bad Aspose practice to append Documents in this way/ this number of times? Are there better / more performant / more efficient methods of accomplishing this that you can recommend?


Thanks for the additional information. We have logged these details in our issue tracking system and will keep you posted here on further updates.

With the additional details sent, do we have any updates on when we will get the fix? alternatively we are open to discuss best practices or more efficient methods that you would recommend to accomplish this. Can we get a consultation Meeting set up with Engineering or architecture to review our usage and provide us with some solutions?


We have good news for you i.e. WORDSJAVA-2279 has now been resolved. The fix of this issue will be included in the 20.2 (next version) of Aspose.Words for Java. We will inform you via this thread as soon as the next version containing the fix of your issue will be released in the next few days.

Thank you Awais, that’s great to hear! Can you go into any detail on exactly what aspects of the issue we brought up were fixed? Was performance improved and/or the memory allocation reduced? In what areas?