none
A very technical (I think) VSTO startup question RRS feed

  • Question

  • What is different on a system before VSTO customized document is loaded and after?

    Let me explain.  We've got a Word customization that takes 58 seconds to load the first time after a reboot, but only 18 seconds thereafter.  Our customization is installed in the GAC, is NGEN'd, and rather large.  We have a shimmed managed Word addin that starts .NET CLR with the STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN flag so that multiple documents don't require all of our assemblies for each document.

    We've also found through experimentation that loading a differently customized document (i.e. a new Word VSTO project) before loading our customized document for the first time (stopping Word entirely beforehand) reduces the time to load from 58 to 24 seconds. 

    We also know that there is something called the VSTO runtime which is separate from the .NET CLR that gets spun-up the first time you load a customization after a reboot.  We need to know what that is, and how we can spin it up without starting Word or Excel so that our users don't have to wait a minute to load their first document.

    Thanx in advance,

    Dave

    PS - Someone please say "Hi" to Catherine Heller and Nirav Shah for me (yes, I'm dropping names in hopes of a quick response from the VSTO team ).

     

     

     

    Wednesday, March 8, 2006 10:02 PM

Answers

  • Thanks, Dave.

    X is known as cold start up time.

    Y is known as warm start up time.

    It is expected that you would see a large difference between warm and cold startups. This is because a lot of memory pages from a large amount of assemblies need to be loaded into memory by the OS - running CLR is not cheap. When you start up your application against in the warm scenario most of the pages are already cached in the memory so this take significantly less time.

    Still, what concerns me is that you are reporting 18 seconds of warm start up. This is huge number and is about 5 times longer than I would expect under normal circumstances.

    To identify the bottlenecks I would first set up the simplest possible scenario - disable all the add-ins and ran the simplest-emptiest VSTO solution. If this results in acceptable start up time then I would throw in a bit more functionality and then test again. And again, and again. As Eric Lippert would put it - "hey, this is tough, but it builds character" :)

    Wednesday, March 15, 2006 2:12 AM

All replies

  • Dave,

    What makes you think that the time difference is the VSTO runtime and not simply the CLR being loaded for the first time. Relative to the CLR the VSTO runtime is quite small.

    Have you tried the case:

    1) Cold machine.

    2) Run (any) .NET application (to load the CLR)

    3) Run your Word customization.

    Let me know...

    Ade

    Wednesday, March 8, 2006 10:18 PM
  • Yep, tried that.  I didn't mention it in my original post, but the way our users open the customized document is from our document management app, which is written in C#.  So, by the time user opens the doc, the .NET CLR is all spun up.

    In an attempt to speed up our app (which is also slow to load) we experimented with an app that would run at login time and call Assembly.Load on some or all of our assemblies, then exit.  It wasn't worthwhile though.

    Thanx for the reply,

    Dave

    Wednesday, March 8, 2006 10:30 PM
  • So I spoke to Eric Carter about this (see... I can name drop too). The runtime is quite small the big overhead is first and foremost loading the Office PIAs and secondly loading some of the large .NET FX assemblies, e.g. System.Xml. But if you're shutting down Word then these should get completely unloaded between the first and second runs.

    Have you considered profiling your application to see what's causing the delay?

    Ade

    http://msdn.microsoft.com/msdnmag/issues/03/01/NETProfilerAPI/

    Thursday, March 9, 2006 9:47 PM
  • I think I was on a conference call with Eric Carter a few months ago.  But I've talked to Rico, have an autographed book by Eric Lippert, and am close personal friends with Melinda Gates.  (That's all true, except the Melinda Gates thing.)

    I figured all of those things would be unloaded when I stop the winword process, but there is something going on.  I'm about to start using CLRProfiler, but I've only ever used that to track resource usage and watch the garbage collection.  However, I'm sure you know how difficult it is trying to watch what Word or Excel is doing.

    Dave

    Thursday, March 9, 2006 10:02 PM
  • This is interesting. Apparently something is going on. One thing I was not clear though is whether same performance issue happens for all VSTO customizations or only the specific one i.e. if you create New VSTO project and press F5 it will still take about 20 secs to load? We are also assuming here the machine has enough memory to not going page as crazy, right?

    You probably measured loading times with your neutral-ness enablig add-in disabled and enabled. Was there any difference? 

    I was trying to recall any such slow performances we have seen in the past and the only thing that comes to mind is this  - CLR tries to verify digital signatures on the assemblies. Here is the crux of the problem: some assemblies (e.g. Office PIAs) are digitally signed in addition to their strong name. When assembly is first loaded CLR tries to evaluate the permission set to grant to this assembly. In order to do this it first collects all the possible information about this assembly (e.g. strong name, location etc - things otherwise known as evidences) and then walks the policies tree to map the evidences to the permission sets. One of the evidences it tries to collect is a valid digital signature. In order to verify wether digital signature is still valid CLR needs to contact the authority that issued the certificate and verify it has not been revoked. Sometimes, on some machines, for some unknown to me reason this was a very slow painful process. After poking around I found that it is possible to disable the check for revocation - in IE go to Tools->Options ... Selected Advanced tab, go all the way down to the Security settings and uncheck "Check for publisher's certificate revocation". This is a long shot and I am not sure this is the reason you are seeing performance issues - but something to try out. 

    Monday, March 13, 2006 5:40 PM
  • Misha,

    I've been concentrating on how running a new "empty" VSTO project affects my existing customization, not so much the other way around.  I have noticed particular difference when running a the same "empty" customization multiple times however.  This is what I've been trying:

    1 - Create a new Word project (WordApplication1.dll) and compile.

    2 - Reboot.

    3 - Open WordApplication1.doc.  This takes X seconds.

    4 - Close Winword.exe.

    5 - Open WordApplication1.doc.  This takes Y seconds.

    You'll see that X is considerably larger than Y.  The difference is even greater if your customization does anything.

    I've tried this with and without our managed shimmed addin enabled, but saw little difference.

    I've tried CLRProfiling and I have the logs.  The first noticable difference (although it's slight) between run 1 and run 2 appear to be in AppDomain.SetupFusionStore(...).  I'm thinking that's a red herring though.

    Dave

    Tuesday, March 14, 2006 3:19 PM
  • Thanks, Dave.

    X is known as cold start up time.

    Y is known as warm start up time.

    It is expected that you would see a large difference between warm and cold startups. This is because a lot of memory pages from a large amount of assemblies need to be loaded into memory by the OS - running CLR is not cheap. When you start up your application against in the warm scenario most of the pages are already cached in the memory so this take significantly less time.

    Still, what concerns me is that you are reporting 18 seconds of warm start up. This is huge number and is about 5 times longer than I would expect under normal circumstances.

    To identify the bottlenecks I would first set up the simplest possible scenario - disable all the add-ins and ran the simplest-emptiest VSTO solution. If this results in acceptable start up time then I would throw in a bit more functionality and then test again. And again, and again. As Eric Lippert would put it - "hey, this is tough, but it builds character" :)

    Wednesday, March 15, 2006 2:12 AM
  • Misha,

    Thanx for the reply.  I did forget to make sure the CLR was spun up after the reboot.  I'll test that.  Also, I'm currently testing with an almost completely empty customization.  Right now, the only code I've added is to repro two possible bugs we've been seeing with Word, but I'll post those to new threads if they turn out to be actual bugs and not "undocumented features."

    I'll also disable our managed shimmed addin, but it provides a valuable service.  It loads the CLR for that process with the multidomain loader optimization.

    Thanx,

    Dave

    Wednesday, March 15, 2006 1:53 PM
  • Hi Misha, We are facing similar performance issue with VSTO document. Unchecking the "Check for publisher's certificate revocation" setting actually helps. Is there any other alternative solution to prevent the verfication of digital signarures?

    Thanks,Satya

     

     

    Tuesday, December 12, 2006 9:22 PM
  • Misha said:

    "After poking around I found that it is possible to disable the check for revocation - in IE go to Tools->Options ... Selected Advanced tab, go all the way down to the Security settings and uncheck "Check for publisher's certificate revocation". "

    This suggestion proved very valuable to me with an Outlook VSTO project. Start times were a painful 15+ seconds, but changing this setting reduced time considerably to <3.  Having another .Net application open (or not) did not appear to make substantial difference to the start time, so I had already assumed that the CLR loading was not the prime issue. Also (in the case of the Outlook VSTO application noted) even when the first line of

    ThisApplication_Startup(object sender, System.EventArgs e)

    was a Console.Beep() - the beep occurred right at the end of the loading process.

    Nij

    Tuesday, January 16, 2007 4:43 PM