As I already stated: Our usage scenario is using Merge Fields to allow our users to create custom templates that are then used to export customer data to the Word format. Each template can contain up to two dozen merge fields or so (although there is no technical limitation in place), each representing a data point in our system, and the template could be used up to thousands of times depending on how many items are being exported.
The code I’ve provided was an example to reproduce the original issue. Our actual code is hooked into our system to get various values and provide them to the merge fields. But we saw the same issues in both our production code and the example code I’ve provided, for both the now-solved performance issue and the still-active risk of unlimited memory growth leading to OutOfMemoryErrors.
We have tested the scenario using shared code example. We have not found much difference in results of Aspose.Words v13.4.0 and v15.10.0. Please check our test results in attachments. E.g v13.4.0 takes 44.10 seconds and v15.10.0 takes 45.89 for 1000 times mail merge.
In terms of memory, Aspose.Words does not have any limitations. If you’re loading huge Word documents into Aspose.Words’ DOM, more memory would be required. This is because during processing, the document needs to be held wholly in memory. Usually, Aspose.Words needs 10 times more memory than the original document size to build a DOM in the memory.
Moreover, we suggest you please increase the heap size. Hope this helps you.
Yes, as I said in my comment, given the appropriate verification file 15.10.0 appears to have resolved the merge fields performance issue introduced sometime after 13.4.0 that was made worse by 15.9.0. This is reflected by the data I attached. It looks like the most critical part of our problem has been resolved.
I understand that the way Aspose Words is currently implemented does not contain any memory restrictions. My concern is that this allows an Aspose Words operation to negatively impact the rest of a system Aspose Words is running inside, even to the point of bringing it down with OutOfMemoryErrors. The solution to this would be to re-work Aspose Words to only load portions of the document into memory as needed, and unload them as they become out-of-scope of any changes. For example, we build our document iteratively, where we insert one item’s worth of data, then move on to the next. After we’ve moved on we no longer need to care about the previous item or make changes to it, so there is no need to have it in memory. This approach would make Aspose Words scalable to any size document.
That would require major re-works, for sure, if it’s even possible, so we have no expectation of such a change. The fixes you’ve provided pushes out the risk of OutOfMemoryErrors to the thousands of items, so for the majority of cases it is adequately performant. It’s just scary that Aspose Words has the capability to grow unbounded.
Increasing the heap size also increases the maximum number of items we can export using Aspose Words, but the risk of a system-halting OutOfMemoryError is still there.
Thanks for your feedback. Please note that performance and memory usage all depend on complexity and size of the documents you are generating. We’re always working on improving performance.
Please feel free to ask if you have any question about Aspose.Words, we will be happy to help you.