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

Free Support Forum - aspose.com

InsertHTML and Document save are slow


we have the current issue, that we insert HTML into a new document. The HTML has some css and tables. The insert takes about 2,5-3 secs. Is there something we can do to get this insert faster?

Also we see that the save method need a lot of time with update fields (should we create another post for this issue?).

We have tracked the methods with jprofiler (see the attchements).

Here is the Application for the the test - we are using Aspose.Words 17.2.0:

This Topic is created by tahir.manzoor using the Email to Topic plugin.


It is to inform you that the issue which you are facing is actually not a bug in Aspose.Words. So, we are closing this issue (WORDSJAVA-1600) as ‘Not a Bug’.

When you execute the code for the first time - JVM loads classes, instantiates buffers, etc. As a result, the code tests mostly JVM, not Aspose.Words. When you execute the code second time, it does not take much time. Please let us know if you have any more queries.

Best Regards,
Tahir Manzoor

Hello Tahir,

sorry to ask again about this issue: Are there any best practice about the performance?

We have the following scenario: We have a document with a lot of insertHTMLs and each of them is a new instance of aspose. So the inserts are all “very” slow as you described it because the JVM loades the classes, buffers etc.

Is there any way to use some classes again or maybe load them at the start? A best practice would be very nice.

Best regards


Thanks for your feedback. We have shared your scenario with our product team for review and will update you with our findings soon.

Best Regards,


Thanks for your patience. We have received response from our product team about your query. Please check the following developer’s comments. Hope this helps you.

There are tons of info about java application performance optimization, like this https://dzone.com/refcardz/java-performance-optimization.

It hardly depends on local environment. It can be completely different for a server that generates thousands documents 24/7 or for a local PC that generate only the one document by demand.

The simplest rule is: the first call of “new Document()” will cause to load all related classes and system buffer instantiation. The static Aspose.Words resources (document styles, fonts, border arts, etc.) are loaded lazily – only when they really needed and after loading they are cached during the session.

So the second call of “new Document()” will not cause class loading. If your JRE uses JIT the behaviour is more complex because of several intelligent levels of byte-code compilation and optimization.

Another performance option is to use all processor’s cores. If you have, for instance, 8 virtual cores and 8000 documents it is better to instantiate 8 threads that will handle 1000 document each. The result will be about 5 time faster than processing all 8000 documents in the single thread.

Also, you should have enough heap space to exclude swapping. Another very important thing – fast disks. Changing HDD to SSD can rise performance twice or even more depending on quantity of disk IO operations.

Hello Tahir,

thanks for your reply. We understand the developer comments and we know about the lazy loading mechanic from aspose. But we have a problem too tell that our customers, imagine following example:

The server is started and the first user is creating a document and he has to wait 4405ms. The next user who creates a document just need to wait 207ms. With a bigger document the numbers are 3m 15s 733ms and 2m 38s 114ms. So you can imagine that our customer is wondering why the same report needs to load on the first time so long and is much faster the second one.

As a workaround we could generate a big document while starting up the machine, but we think this just a workaround. Maybe you could implement a function that, we can tell aspose to load eager instead of lazy? Or is there anything else we can do?


Please note that performance and memory usage all depend on complexity and size of the documents you are generating. The answer of your query is well explained in my previous posts. We have closed WORDSJAVA-1600 as ‘Not a Bug’.


Thats okay, but maybe discuss the suggestion with eager loading?


We have logged a feature request as WORDSJAVA-1628 in our issue tracking system to use eager loading instead of lazy loading in Aspose.Words. Our product team will look into the possibility of implementation of this feature. Once we have any information about this feature, we will inform you via this forum thread.

Please let us know if you have any more queries.


Thanks for your patience. It is to inform you that the issue which you are facing is actually not a bug in Aspose.Words. So, we have closed this issue (WORDSJAVA-1628) as ‘Not a Bug’. We are quoting developer’s comments here for your reference.

You are mixing JRE class loading and Aspose.Words resource loading.

When your application calls Aspose.Words for the first time - JRE loads classes from Aspose.Words’ Jar. The JRE can be lazy or eager - it depends on local JRE settings. We can’t alter JRE behavior from Aspose.Words application.

Some Aspose.Words classes loads resources from the Jar when the user application calls them the first time. Yes, it is mostly lazy loading. But the volume of these resources is very small comparing to all classes in Aspose.Words’ Jar. No more than 1% - so eager or lazy loading of Aspose.Words resources will not change the whole picture.