i postet this problem yesterday as a private post, so i am not sure
that anybody saw it. So i post again. The original post is here: Free Support Forum - aspose.com
We have an urgent performance problem in our production enviroment so we need a sollution ASAP.
To demonstrate the problem i have attached our template and here are two samle code snippets:
this needs on my workstation about 30 seconds:
Document doc = new Document(“Test.dot”);
foreach (Bookmark bookmark in doc.Range.Bookmarks)
{
bookmark.Text = string.Empty;
}
this needs about 20 seconds:
Document doc = new Document(“Test.dot”);
doc.MailMerge.Execute(new string[] {}, new object[]
{});
This is no production code, it is just to demonstate the issue. In our
production system we end up with more than 1 minute per document… so
rigth now it is completly useless
The performance was good until 2.5.2, from 3.0.0 there is this issue (in all 3.X.X versions),
unfortunately we did not discovered it before today in our production
enviroment.
Right now this is a huge problem for us, so please help us to resolve this problem asap.
Interesting document I must say. You’ve got almost 500! bookmarks. Do you just want to set their text to empty string or you want to do something else as well?
i do not want to set all the text in the bookmarks to empty string, my
sample code is only for demonstration of the performance issue, but in
the real code, i set lot of these bookmarks to empty strings depending
on the values of some external imput. This template contains text for
all different versions of this document (slightly different versions
for different customers) and i just set those bookmarks to empty string wich i do not want to show to the particular customer.
Anyway, i know, that the bookmark count is rather large, but we have
other similar documents, where we have no performance problem. And with
Aspose.Word 2.5.2 it is pretty fast also with this template. So the bookmark count alone is
probably not the problem.
I attach now another version of this template. I stripped out the
middle part with tables, the bookmark count is allmost the same, but
the speed is much better. It seems to have something to do with theese
tables.
Thanks, it was indeed related to tables. I fixed this and will publish a hotfix in the next couple of days. The document that took 30 seconds before now takes under 5 seconds, I think this time for processing 500 bookmarks is good. Let me know if you had better performance from earlier versions.
Tahnks. Can you provide some beta version of this hotfix? Right now we
have serious problems because of this performance issue in our
production enviroment, so it would help.
Under 5 seconds for 500 bookmarks seems reasonable, but i will make some tests when i get the thotfix.