SteinerA

Hi

We are facing serious performance issues with document level addins for Office 2003 and VSTO2005.

It take very long time for word to START loading the customization assembly (in some cases, even up to 2 minutes)

I have been reading some posts on the subject and we have been following MSDN best practices and recommendations as close as possible.

Especially followed this useful link:

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=290423&SiteID=1

and that is where I learned about the "PIA certificate trick".

Still, even after implementing this, I still see the same behavior.

Feeling in a deadlock at the moment since I am running out of fresh ideas ¨C any help will be greatly appreciated.

Thanks

More information:

Quick briefing over what we have:

  1. Document level customization using VSTO2005
  2. Assembly is located in the machine's GAC
  3. We create and start the customized documents from a separate managed Application (SO CLR is already loaded)
  4. loading procedure consists of the following stages:
    1. Preps:

i. Creating a DOC based on the DOT

ii. Populating Cached data members using DocumentServer object

    1. Launch Word:

i. Create a new word application

ii. Load the document

    1. Document loading:

i. No control over what's happening here¡­

    1. VSTO Designer generated code:

i. Initializing the ThisDocument object

ii. Deserializing the cached data members

iii. Raising the Document startup event

    1. Document startup event

i. Our customization code starts running

ii. Toolbars, XMLNodes etc.

What we consider "bearable" is around 12-15 seconds until the document is loaded and responsive.

Unfortunately, loading time from client machines from 12 seconds to 3 minutes.

So the "Best" result we get is what customers call "bearable".

Logging and timers reveal that on machines that loading time is considerably long the part that takes the longest is part 'B+C' when Word is loading and opening BEFORE the customization assembly code even start running.



Re: Visual Studio Tools for Office Document level customization slow loading time

Douglas H. Troy

Steiner -

Good to see someone else discussing this, just haven't had the time. I too have experienced seriously long load times, although mine not nearly as Earth shattering as yours; our longest load time is just over 1 min, which is still unacceptable to most users.

After installing my assembly up into the GAC, and doing some testing, I noticed that the Native Images are almost never used, therefore, we gain no real benefit of NGEN compilation. In some cases, load times were actually longer when everything was in the GAC.

I came up with an idea, I've yet to even try to implement, which involves loading Word itself, into memory, keep it hidden, and load documents as needed; avoiding that loading/unloading of Word and framework that goes with it ...

Again, I've not tried this, nor do I know if it would even work, but I thought I would put that idea in your head as well.

I'd also like to know if there are performance differences between a VSTO 2005 SE Office 2007 solution and a VSTO 2005 Office 2003 solution. Do we gain anything by moving our users to the newer suite (performance wise). Something else I've yet to check into ...







Re: Visual Studio Tools for Office Document level customization slow loading time

Dennis Wallentin

Steiner,

I don't have any bright ideas to cut the start time but I would like to know the hardware configuration on the tested machines (CPUs, RAM)

Douglas,


After installing my assembly up into the GAC, and doing some testing, I noticed that the Native Images are almost never used, therefore, we gain no real benefit of NGEN compilation. In some cases, load times were actually longer when everything was in the GAC.

Thanks for the information which save me the time to explore NGEN.exe.
Where there any specific circumstances that increased the load times

TIA






Re: Visual Studio Tools for Office Document level customization slow loading time

Douglas H. Troy

Dennis:

I cannot give you a specific 'case' where I saw an increase in load time; but I can tell you that putting the assembly in the GAC did increase load times more often than not ...

There is an excellent write up on NGEN here:

Speed: NGen Revs UP Your Performance

The reason the native images never load, I suspect, is due to the following statement (taken from the article just mentioned)

"One more detail is also worth mentioning. If you are using strong-named assemblies, NGen is probably not a gain for you unless they are in the Global Assembly Cache (GAC). The CLR loader does extra validation on strong-named assemblies that aren't in the GAC, which causes nearly every page in the native image to get touched, thereby usually completely eliminating any startup gains that would be realized through the use of NGen."

I believe there are strong named assemblies that are causing the problem described above; which ones, I do not know ... but I can tell your for certain, when looking at the process, the native image for the customization was not being loaded ... despite the fact that it and all referenced assemblies are up in the GAC (zap cache).

Machine Specs:
P4 2Ghz 1gig ram 40gb 7200rpm EIDE drive.
First time startup load time: 1min 12seconds (single customization with 1 external dependency)
Load time following: 20 - 30 seconds (never consistent)








Re: Visual Studio Tools for Office Document level customization slow loading time

Dennis Wallentin

Douglas,

Thanks for poiting me to that very good article which I now print out :)

It's remarkable that a configuration like Your's computer need > 1 min to load. As for the NGen I simple need to read more about it in order to see the logic with NGen and strong names are not a good approach.






Re: Visual Studio Tools for Office Document level customization slow loading time

Praveen Bengeri

Hi Steiner,

What is the evidence you are using to full trust the VSTO assembly

If your assembly is signed using a digital certificate and the evidence is a publisher certificate, then you may want to check out if the time is being taken in checking for Certificate Revocation List (CRL) for the publisher certificate.

You can do this by temporarily (yes, temporarily... please reset after the test) disabling the CRL check by going to:

Tools->Options->Advanced Tab, in ¡°Internet Explorer¡± and unchecking "Check for publisher's certificate revocation" checkbox.

Close all running instances of Word, Internet explorer and retry launching your VSTO customized document.

If that shows any performance difference then you may want to check your internet connection settings like "Automatically detect settings", auto proxy server etc..

Hope this helps,

Praveen





Re: Visual Studio Tools for Office Document level customization slow loading time

SteinerA

Praveen, Dennis, Douglas

First things first... Thak you very much for joining in on this discussion.

Dougls:

Your idea of loading a "Hidden" word process is a great demonstration of "out of th box" thinking :)

We too have been contemplating on this approach but what deters me the most is the fact that Document customizations under the same process have their own set of issues (i.e, event handlers are being handled by all documents etc...).

Don't get me wrong - this CAN work, but before I dive into this abyss, I want to make sure there is a light at the end of that tunnel.

Praveen:

We already implemented the CRL appaorch - still, we get the same results.

Our CASPOL evidence is "Strong name" based. meaning that we add a security configuration to trust all assemblies signed with our SNKey.

Dennis:

Our assemblies are stored in the GAC. I will read the NGEN article, but if i understand you correctly, if my Assemblies are GAC'd - will NGEN them help

Thanks again guys - feels good knowing we are not alone out there and that we have people like you on our side :)