Virtual-environments: Devenv takes a long time to run the first time

[kudaba]

Describe the bug
In the all current versions of MSVC (2017 and 2019), the first time devenv runs it goes through some internal 'new user experience' work that takes 3-8 minutes. Since this time is outside of the control of users would it be possible to run devenv when building the environments so users don't have to constantly pay the cost?

Virtual environments affected

• [ ] macOS 10.15
• [ ] Ubuntu 16.04 LTS
• [ ] Ubuntu 18.04 LTS
• [x] Windows Server 2016 R2
• [x] Windows Server 2019

Expected behavior
Using devenv to build a project or solution should start compiling right away instead of just idling for many minutes.

Actual behavior
Unfortunately my repo is currently private, but from what I can gather using devenv over msbuild on any solution or project should cause this. In my case I can't use msbuild because of how the projects are setup.

The following image shows the problem, devenv is executed at line 28 but doesn't even show the startup banner for 8 minutes.

[alepauly]

Thanks for reporting. @kudaba do you have a sample first devenv command line that you run and causes this to happen? We might be able to warmup the instance ahead of time.

[kudaba]

Sure, here's a trimmed down version of my job:

  Windows:
    runs-on: ${{ matrix.os }}
    env:
      MSBUILD_PATH: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.com
      SLN_PATH: path\to\application.sln
    strategy:
      matrix:
        os: [windows-latest]
    steps:
    - uses: actions/checkout@v1
      with:
        submodules: recursive
    - name: Setup Nuget.exe
      uses: warrenbuckley/Setup-Nuget@v1
    - name: nuget restore
      shell: cmd
      run: nuget restore "%SLN_PATH%"
    - name: compile debug
      shell: cmd
      run: |
        "%MSBUILD_PATH%" "%SLN_PATH%" /build debug
    - name: compile release
      shell: cmd
      run: |
        "%MSBUILD_PATH%" "%SLN_PATH%" /build release

And updated outputs showing the time between nuget and the first compile:

And the time between the first and second compile

[alepauly]

@kudaba sorry for the delay, I'm working on this now and gathering data for the Visual Studio team to help out here.

[github-actions[bot]]

This issue has not had any activity for 45 days and will be closed in 45 days if there continues to be no activity.

[alepauly]

I gathered some perfviews and sent them to the VS team who confirmed this is due to MEF composition on startup. Running devenv /updateconfiguration should alleviate it. We already have code that should be running this but apparently it's not doing the trick so we should investigate why.

[andy-mishechkin]

I have tested builds of some my solutions in Canary builds and I didn't find any big delays. 'devenv /updateconfiguration' is executed now when MMS provisioner runs on VM, and perhaps it already fixed this issue.
Please test it once again.
If you still get this issue, please provide your solution for test building.

[kudaba]

I went through a bunch of recent builds, and at first it looked like it dropped from 3 minutes to 1 minute for a while, but the 3 recent builds show some pretty erratic behavior. I have 2 devenv jobs per build and the initial devenv launch timing is as follows:

Mon, 16 Mar 2020 06:07:48 GMT - 1 sec, 3 min
Mon, 16 Mar 2020 06:06:20 GMT - 3 min, 1 min
Mon, 16 Mar 2020 05:42:29 GMT - 3 min, 1 min

Only one case was it fast (the most recent), but all others were either almost exactly 1 minute (+- 4 seconds) or 3 minutes (+- 20 seconds).

[maxim-lobanov]

Hello @kudaba , we have tweaked VS a bit.
Could you check one more time?

[kudaba]

Sure: 4 builds had the following timings in seconds between the first and second executions of visual studio:
First|Second
-|-
60|8
114|6
87|9
68|7

It's a small sample set but seems to be heading in the right direction.

[maxim-lobanov]

Hello,
Our latest result (reducing VS initialization time to 1-1.5 minutes) was achieved by invocation devenv.exe /updateconfiguration during deployment. It does first VS initialization and improves build time.

Unfortunately, we don't see more ways to improve it because it seems that remain time comes from VS execution (probably, initialization of solution or something similar)
I am going to close this issue for now. Please let us know if you see other ways to improve it.

[kudaba]

It's a lot better than before, thanks for taking the time to look into this. I can imagine the rest of the cost is probably just spinning up from the HD into the ram cache, etc, etc. This still saves a lot of minutes per run.