Develop Office Client Applications using Visual Studio
With the SP1 work winding down, I thought that I’d take a moment and discuss three new performance improvements that are going into VSTO for SP1. We have listened to your feedback and understand that startup time is a major issue, and so we have focused on attempts to make the VSTO runtime load faster.
In this article, I will be delving into these features and how you can take advantage of them. The most important feature is Fast Path loading, which is a loading path for the runtime which is as fast and as lean as possible. In addition, we updated the form region and ribbon discovery process so reflection is not required in most cases. Plus, I will also share a few of the numbers we gathered during this effort so that you can get a before and after picture.
The Fast Path is a new way to load and launch VSTO addins that is much faster than the current launch path. However, it achieves this speed by bypassing a few of the steps that would normally happen during addin launch. The following conditions must be met in order to use the fast path:
When the fast path is in use, the following steps will be skipped:
Notice that the requirement that the add-in is deployed into the secure location on the user machine allows us to relax the security verifications done at runtime without compromising the security of the machine. Relaxing these expensive checks is what contributed the most to the improvements in startup time.
In order to take advantage of Fast Path loading, an addin has to be deployed via an MSI. As a consequence, these addins also will not be able to automatically check for updates.
As mentioned in a previous blog post, VSTO reflects over the addin assembly in order to find Ribbon extensions. On particularly large assemblies, this can be quite time consuming. While there have been manual workarounds for this behavior in the past, we are now including Ribbon extension types directly into the VSTO manifest. If there are no Ribbon extensions, then an empty list is placed in the manifest, which will tell the VSTO runtime that reflection is not necessary.
In order to take advantage of this improvement, the addin must be built (or rebuilt) with Visual Studio 10.0 SP1, and the addin must be loaded with the SP1 version of the VSTO Runtime. The addin must also be targeting .Net 4.0. If you attempt to load an SP1 addin with a RTM runtime, or if you load an RTM addin with the SP1 runtime, all of the ribbon objects will still be discovered and loaded; the runtime will just have to use reflection to find them.
Of course, if your code already overrides CreateRibbonObjects or CreateRibbonExtensibilityObject as mentioned in the above blog entry, then this optimization does not apply to you. The reason why this was implemented is because many people are not aware of this optimization, and we want to ensure that we are as performant as possible by default with as little manual optimization as possible.
To better visualize the new ribbon xml, here are two examples of its intended use:
<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="ExcelAddIn14">
<vstov4.1:ribbonType name="ExcelAddIn14.Ribbon1, ExcelAddIn14,
Version=220.127.116.11, Culture=neutral, PublicKeyToken=null" />
That addin had one ribbon type, and the class is called ExcelAddIn14.Ribbon1, and it is part of the ExcelAddIn14.dll assembly.
Here is one with no ribbons:
<vstov4:appAddIn application="Excel" loadBehavior="3" keyName="ExcelAddIn15">
<vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1" />
The empty ribbonTypes list serves to tell the SP1 runtime that doing the reflection is unnecessary. This will save a lot of time during VSTO startup.
When loading an Outlook addin that has Form Regions, the VSTO Runtime uses reflection to discover Form Region factories and match them up with Form Regions registered with the addin. This had the potential to inflict a serious performance hit, especially if the addin assembly contained a lot of different types.
To eliminate this performance hit, the name of the factory is now being included in the addin manifest. Now when Outlook requests the factory from the addin, the addin knows immediately which class to instantiate and doesn’t need to reflect over every type in the assembly to find the appropriate class. If you look in the new SP1 manifest, you can see the new information:
Like the Ribbon aware manifest above, the SP1 runtime is capable of loading an addin with Form Regions that was built with the RTM version of VS, and the RTM runtime can load an SP1 addin. You just won’t be able to take advantage of this improvement.
Below are some of the numbers that we tracked on startup time during this effort. These numbers were collected on a machine in a ‘cold’ state (everything in memory flushed out to disk, superfetch disabled) in order to give us the most consistent results during our work. In addition, there are no other applications running at the time that Outlook was launched, and all addins except for the one that we were testing was disabled.
There four startup times of interest are as follows:
As you can see, there are many performance improvements to the VSTO Runtime coming in Visual Studio 2010 SP1. Not only that, but many tweaks that used to require extra work (such as working around Ribbon reflection) are now available out of the box with no interaction on the user’s part. This will help you deliver VSTO addins that are faster to your end-users.
UPDATE: Visual Studio SP1 Beta is now available!
Are the startup times in milliseconds?