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

Free Support Forum - aspose.com

Aspose.Words.Document constructor is very slow on the first call

Aspose.Words Product Family
#1

The attached zip file contains the Outlook email file “FW multipage start and next.msg”

The following chunk of code (suggested by Aspose in [an earlier post](https://forum.aspose.com/t/39203)) constructs an Aspose MailMessage and then writes the MailMessage content out as an HTML stream, which is used to construct an Aspose.Words.Document. I’ve added the line numbers for clarity.

Aspose.Email.Mail.MailMessage msg = Aspose.Email.Mail.MailMessage.Load(@"FW multipage start and next.msg"); 
MemoryStream ms = new MemoryStream();
msg.Save(ms, Aspose.Email.Mail.SaveOptions.DefaultHtml);
ms.Position = 0;
Aspose.Words.Document doc = new Aspose.Words.Document(ms);

The problem is that line 5 that constructs the Document takes about 30s.

When I debug this chunk inside VS2013, once I’ve stepped line 5 (and waited 30s!), I can drag the cursor back to line 4 and step the code again, and this time the constructor takes less time, maybe 20s.

My questions are:

  1. Why is the constructor so slow?
  2. Why is it faster on the second call?
  3. How can I speed it up?
  4. Is there some sort of caching or JIT compilation or serialization going on that makes it slow first time around?
  5. Or is there a problem with the email document itself?
  6. How could I identify problematic email messages?
#2
Hi Brian,

Thanks for reporting this problem to us. We tested the scenario and have managed to reproduce the same problem on our end. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-13178. Our product team will further look into the details of this problem and we will keep you updated on the status of correction. We apologize for your inconvenience.

Best regards,
#3

Thank you for the response Awais.

I'm still unclear whether the lengthy execution is because there is a fault in the constructor or because the email content itself is badly-formed.

If the fault is in the Aspose.Words.Document constructor then I'll just have to wait for you to fix it,

But - if the problem is in the email content, perhaps you can suggest how I can modify the content to speed up the Aspose.Words.Document constructor. The message content loads into an Aspose.Email.MailMessage very quickly, so I could modify that object before I save the content out as a Stream and use the Stream to construct the Aspose.Words.Document.

Can you tell me which of these two scenarios applies here? Or is there some other explanation?

Brian

#4

Hi Brian,


Regarding WORDSNET-13178, our product team has completed the work on your issue and has come to a conclusion that this issue and the undesired behavior you’re observing is actually not a bug in Aspose.Words. So, we will close this issue as ‘Not a Bug’.

Aspose.Email generated MHTML file contains several external resources which aren’t available by some reason. Aspose.Words tries to retrieve these resources and spends a lot of time (about 30000ms) for this. This is expected behavior and this is not a bug. To avoid this the LoadOptions.WebRequestTimeout property can be used as follows:

var lo = new LoadOptions();
lo.WebRequestTimeout = 100;
Document doc = new Document(“aspose.email-6.2.0.mhtml”, lo);

Loading of the file with this option takes about 3000ms on our end. The second call takes about 300ms. This is a JIT compiler’s feature, not a performance issue of Aspose.Words library. When a managed method is called first time, the JIT compiler is triggered, and starts to compile the method for the current and future calls. The compile process can take some time and this is a reason of the second issue.

Best regards,
#5

Thank you for such a comprehensive reply Awais.

In follow-up, I have seen that after the JIT compiler has run, aspose operations in my project are rapid. But if I then leave the computer alone for 20 min or so, when I start to use my project again the delay due to JIT occurs once more.

I also found this article showing how to programmatically force the JIT compiler to run on an assembly.

My further questions are:

  1. Is there any control over the lifetime of native images generated by the JIT compiler?
  2. Would it be wise to use the article code to force the JIT compiler (on a different thread) to run on the entire aspose.words assembly?
  3. Or can you suggest the single aspose.words method that I should JIT compile?
  4. Or should I be using ngen on all the assemblies (including aspose) in my project?
  5. Or do I just have to accept that the first operation is going to be slow?

Brian

#6

Hi Brian,


Thanks for your inquiry. We have logged your comment in our issue tracking system against the linked issue and will keep you informed of any further proceedings.

Best regards,
#7

Hi Brian,


After further investigation our product team has found that this is infact Aspose.Words initialization issue, not the JIT compiler feature/bug. Aspose.Words component initialization happens to take a long time in some cases. We think we can fix this in our code and have logged a separate issue WORDSNET-13212 for this delay in ‘first call’ problem.

Regarding the main issue (WORDSNET-13178) - it is not a bug and can be fixed with the WebRequestTimeout property. Loading your file with this option takes about 3000ms on our end.

Best regards,
#8

The issues you have found earlier (filed as WORDSNET-13178) have been fixed in this .NET update and this Java update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.
#9

2 posts were split to a new topic: Saving to PDF first time is slow

#10

2 posts were split to a new topic: Document constructor is slow on the first call